[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnash-dev] Gnash initialization
From: |
strk |
Subject: |
Re: [Gnash-dev] Gnash initialization |
Date: |
Fri, 5 Nov 2010 10:17:33 +0100 |
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