[gst-devel] Sink autodetect and async state change
in7y118 at public.uni-hamburg.de
in7y118 at public.uni-hamburg.de
Mon Jul 28 07:16:14 CEST 2003
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
- 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 (custom code to check if it is likely to be used) 
 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
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
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:
> 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
> 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.
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
More information about the gstreamer-devel