From: Tim O. <ti...@ca...> - 2003-07-31 11:34:38
|
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 in...@pu... 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 <ti...@ca...>: > > > 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 > > gst...@li... > > https://lists.sourceforge.net/lists/listinfo/gstreamer-devel > > > > > |