[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gnash-dev] Re: sound_handler.h

From: strk
Subject: [Gnash-dev] Re: sound_handler.h
Date: Thu, 30 Oct 2008 15:43:57 +0100

[moved to gnash-dev, for broader review]

On Thu, Oct 30, 2008 at 02:29:12PM +0100, Klaus Rechert wrote:
> Hi,
> initially this easier than IRC ;)
> class InputStream {
>    [...]
>    @param nSamples
>        ///     Number of samples to fetch.
>        ///     It is expected that the fetcher fetches samples in multiples
>        ///     of 2, being each couple composed by a sample for the left
>        ///     channel and a sample for the right channel, in that order.
>    [...]
> makes no sense to me. usually a sample is considered as a "complete 
> sample" or sample pairs (stereo).

Good to hear this.

I was discussing this with zou on irc, was the last thing indeed,
couldn't figure that out.

It's fine to me to talk about "sample pairs" and fetch "sample pairs"
directly, which is basically what that documentation requires.

The only difference is that instead of fetching 32bit numebrs we
fetch 16bit ones and require to fetch in couples.

> E.g. DEFINESOUND::sampleCount is not affected by mono/stereo. This will 
> confuse people...

Ah, so you suggest we refer to "sample pairs" when we count them ?
Should the interface be something like this then:

        void fetchSamples(boost::int32_t* to, unsigned int nSamples)=0;

If so, isn't thre a need to specify byte orders for those 32bit numbers ?

> I also propose to move
> virtual unsigned int get_duration(int sound_handle) = 0;
> virtual unsigned int tell(int sound_handle) = 0;
> virtual void reset() = 0;
> to the InputStream class.

Uhm.. not sure abou this.
My plan was to use InputStream for both embedded and streaming sounds...

> Also not sure to declare InputStream inside the SoundHandler. Makes the 
> design somewhat inflexible. I'd rather use an InputStream instance as a 
> constructor argument for SoundHandler class.

Maybe this wasn't clear... in the new vision the SoundHandler acts as a mixer
and will mix up input streams.

So, at any given moment, you can plug or unplug InputStream instances.
Could be 4 instances of an event sound, 1 instance of an embedded sound stream
and 1 instance of a streaming external sound.

No problem moving the definition out of suond_handler, but it's really a:



reply via email to

[Prev in Thread] Current Thread [Next in Thread]