Re: [Gnash-commit] /srv/bzr/gnash/trunk r11654: Finally fix testsuite for ffmpeg by introducing a proper AudioInput interface.

[strk]

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
operations.

> 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 ?


--strk;

 Free GIS & Flash consultant/developer      ()  ASCII Ribbon Campaign
 http://foo.keybit.net/~strk/services.html  /\  Keep it simple!