[gst-devel] Sink autodetect and async state change

[Tim Otten]

Re: Benjamin

I spent a while trying to decide whether the auto-launch/die behavior
makes things bad, good, acceptable, or irrelevent. There's no good
heuristic for deciding if the user 'really' wants a daemon to be
auto-launched (except, of course, asking her). I don't really think
GStreamer can solve interaction problems at the daemon/sink level --
that's really up to app writers and distro's. I would be happy if
GStreamer just chose _some_ sink that would work by default.

Re: Steve Baker

> Another thought is that this auto-detection stuff might be too generic
> and useful to put in the gconf helper lib, but is it really worth making
> another tiny lib for those who don't want the gconf dependency?

I went ahead and put some related functionality in a new module. I don't
know if it'll help any or not, but I did learn a bit while writing
it. Take a look at:

http://unix.cap.american.edu/~tim/csc/gst

A 'listselector' (silly name) element runs through a list of
elements/pipelines (described in a text file) and chooses the first one
which seems to pass the state-change-test. It then sets up ghost pads to
wrap around that pipeline.

- Tim

P.S. I'll be driving for the next couple days, so I may not follow up on
this soon.

P.P.S. The .tar.bz2 is based on the gst-plugin template. The only
substantive files are README and gstlistselector.[ch].

On Mon, 28 Jul 2003 in7y118 at public.uni-hamburg.de wrote:

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