[gst-devel] Sink autodetect and async state change

[in7y118 at public.uni-hamburg.de]

Hey, that's great that someone finally does this.
Your approach has some problems however. Lemme first explain a bit:
There are two kinds of audio sinks: The sound server sinks (esd, arts, ...) and 
the direct hardware access sinks (oss, alsa). If the plugins are installed, the 
corresponding libs are available (otherwise the plugins aren't built 
obviously). If you now instantiate such a plugin and set it to PLAYING, the 
plugin will make sure it can output sound (or error out). The direct plugins 
try opening the device and if that fails they error out. But the sound server 
plugins will start the sound server and see if that works. This opens a can of 
worms:
- esd ungrabs the sound device after X time when not outputting sound. Now 
direct access plugins can happily grab the sound device. Even artsd could now 
be started and grab the sound device. So likely any plugin will work even 
though you want esd.
- Same goes for people who want to use oss. They have no server started and are 
not outputting sound. But if you instantiate a sound server element it will 
happily start the sound server and tell you it successfully worked.

The recommended solution make autodetection somehow like this:
for every sound output we know of from an ordered list do
  if (installed)
    if (custom code to check if it is likely to be used) [1]
      use it;
next

[1] This would probably check for the sound server plugins if the server is 
running and not use it if the server isn't running and return TRUE for every 
hardware plugin

You would probably want to check esd, artsd, alsa, oss (in that order).

I know that Steve Baker wanted to work on this, there was a discussion about 
this on the list some months ago. I don't know what the state of his work is 
though.

Benjamin


PS: You could probably have ignored the async state changes and just returned a 
failure. It's not used anyway afaik.
PPS: If we do this in HEAD (or port it later), it's another nice thing to do 
with interfaces and ranks. 



Zitat von Tim Otten <tim at cap.american.edu>:

> I recently filed:
> 
> http://bugzilla.gnome.org/show_bug.cgi?id=118033
> 
> which concerns autodetection for audio sinks. I don't know much about
> GStreamer or media systems in general, so I decided that I was The Right
> Man For The Job. My test code
> 
> http://unix.cap.american.edu/~tim/csc/gst-detect-sink/
> 
> mimics the approach from the xine-libs autodetection routine -- try each
> module and look for errors. There are two tests in particular: (a) can we
> instantiate the audio sink? (b) can the sink handle a switch to the PLAY
> (or READY) state?
> 
> My main concern is with (b). An element can change states asynchronously,
> but I can't find any examples among the sinks. test4 includes some BS
> which calls gst_element_wait_state_change and then checks if the PLAY (or
> READY) state was achieved. Is this reasonable?
> 
> At any rate, it seems to work with esdsink, osssink, and artsdsink on my
> Debian unstable box. I'd appreciate comments/test results from others. If
> it seems to work generally, I'll try to repackage test4 as a
> voodooautomagicalaudiosink module.
> 
> Tim Otten
> tim of cap of american of edu
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
> http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>