Re: [Gnash-dev] Gnash initialization

[strk]

On Fri, Nov 05, 2010 at 09:42:34AM +0100, Benjamin Wolsey wrote:

> 1.  Per-run resources: 
>       * sound_handler because it stores the parsed sound data (I don't
>         like this design, but it's how it is) (also, in a separate
>         issue, the sound handler may be split into separate classes
>         eventually). 

About this, my plan for a refactoring would split the current
sound_handler into 3 distinct services:

 1: The place to which you register sounds and aux streamer and
    from which you extract a mixed stream of output samples.
    This is currently what the base sound_handler class does.

 2: The small device used to mix 2 audio buffers togheter.
    This is currently implemented by a stateless virtual
    mix() function by subclasses (SDL, haiku and aos).

 3: The output device, also known as "sink" in gstreamer terms,
    which is where the mixed sound ends up going.
    This is currently implemented by subclasses, all of which
    currently also setup a polling thread to fetch the samples
    out of mixer (1).

It would help to split those services because you may want to use
an SDL mixer even if you won't send final output to an audio card
(what dump-gui is doing now).
Or, you might want to use gstreamer or direct alsa for output device
but still keep SDL for mixing.

In any case, for the topic of this thread, the 3 classes scope 
would be:

 1:(state) : per-run 
 2 (mix)   : per-session (mixer is actually stateless)
 3 (sink)  : not sure, but sounds like per-run 

Main difficulty in focusing the sink is that current sinks are
_active_ (they do the polling) but we sometimes also want to 
create push-based ones (ie: the core or hosting app would have
the responsibility of fetching from the [state] and pushing
it to the [sink]).

--strk;

  ()   Free GIS & Flash consultant/developer
  /\   http://strk.keybit.net/services.html