[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnash-commit] /srv/bzr/gnash/trunk r11654: Finally fix testsuite fo
Re: [Gnash-commit] /srv/bzr/gnash/trunk r11654: Finally fix testsuite for ffmpeg by introducing a proper AudioInput interface.
Fri, 27 Nov 2009 19:12:59 +0100
On Fri, Nov 27, 2009 at 04:27:48PM +0100, Benjamin Wolsey wrote:
> > Yeah! Can't wait to have some time to look at this ! :)
> Don't expect too much - it only stores the values somewhere and pretends
> to be an input device,
That's exactly what I expected :)
> The advantage is not that it does anything useful, but that it passes
> the testsuite without ifdefs in libcore and shows some of, but not all,
> the things that a proper AudioInput would have to implement.
I suggest you take a look at the doc/DESIGN file and try to figure
how should the new input appear in the diagram.
The way I see it is that microphone should be closer to sound_handler
that to MediaHandler. That is, a module that deals with devices, not
media. The MediaHandler should be in charge of encoding/decoding
> There is also some need to work out where to store the input devices,
> because Camera and Microphone are the last two classes to derive from
> as_object when they shouldn't do.
For the current design it seems they should be in MediaHandler
(altough as mentioned I'd put them in a couple of new handlers, or
mics in sound_handler and camera in a new one).
> The requirement is that Microphone.get(x) should generally return the
> same object, *but* with the proviso that microphones can be added and
> removed; what happens when you do Microphone.get(1), unplug Microphone
> 0, and then do Microphone.get(1) again? Does the first Microphone object
> become invalidated? Does it become the same as (now) Microphone.get(0)?
Uhm, are hot-pluggable microphone devices available on the market ??
> Microphones also have an index property; can this change? None of this
> can really be tested automatically because it involves either manually
> plugging hardware, or OS-dependent creation of audio inputs, but
> wouldn't be hard to do manually (anyone reading with some spare time
> could do it - any volunteers?).
For testing we'd need "Null" implementations for those device handlers.
Again, we did this for sound_handler.
> At any rate, we need to store a list of input devices that can be
> associated with a single as_object somehow and returned when requested.
> Exactly how to do it depends on the answer to the questions above.
For anyone who's planning to test this: be sure to test if the Object
returned by Microphone.get(X) changed in running movie A changes
it in running movie B. That is... are we actually configuring and querying
a system device trough actionscript ?
Free GIS & Flash consultant/developer () ASCII Ribbon Campaign
http://foo.keybit.net/~strk/services.html /\ Keep it simple!