GNOME Bugzilla – Bug 118033
Autodetect audiosink at run-time
Last modified: 2005-03-10 17:01:07 UTC
I'm not sure if this bug should be filed against the sound capplet or against GStreamer, but the two should agree on the default sink. By default (on Debian unstable), "Sound Server Startup" is disabled and GStreamer is set to use osssink. If I enable "Sound Server Startup", then GStreamer applications break -- unless I'm familiar with GStreamer and GConf. GStreamer should be automatically aware of the sound server. Two obvious solutions: 1) Have GStreamer consult GConf key desktop/gnome/sound/enable_esd and forward audio to osssink or esdsink. Perhaps write a 'gnomesink' plugin to handle this, and use 'gnomesink' as default sink. 2) Create GConf key desktop/gnome/sound/manage_gstreamer_audiosink. If enabled, then sound capplet will update system/gstreamer/default/audiosink depending on value of desktop/gnome/sound/enable_esd. Enable manage_gstreamer_audiosink by default. Neither solution forces control-center or gstreamer to depend on the other.
It's definitely a GStreamer bug. This is one of the reasons GStreamer is "0.6" instead of "1.0". The problem is actually bigger than this, since GStreamer should cooperate with KDE and other DEs as well. I think the plan is to create a 'sensible-audiosink' plugin that will attempt to guess the correct plugin to use. In that case, the gconf key would be an override, so if system/gstreamer/default/audiosink="osssink", it will prefer osssink over any other. The question left over is: how does one detect an appropriate audiosink? Someone needs to slog through this problem and come up with a good solution.
Still a problem in 0.8.
Soon after I posted this, I read Xine's autodetection code, read about the GStreamer API, and tried writing a plugin. The approach was to configure the system-wide default the for audiosink key to something like "listselector filename=/etc/audiosinks", and that file had an ordered list of possible audiosinks, like: esdsink artsdsink alsasink osssink sync=false I got it to work in a bunch of tests on my system, but it wasn't clear if it was a hack or a nice solution, and no one ever commented on whether it actually worked for them. http://sourceforge.net/mailarchive/forum.php?thread_id=2845913&forum_id=5947 I haven't really looked at GStreamer since.
This is Debian bug <http://bugs.debian.org/284210>. (I've updated GNOME/Gstreamer versions and bug title.)
Another problem is updating the gconf keys. I don't know wether it is relevant or not to have a different audiosink configuration key for gnome and gstreamer apps, but I think it'd be nice to set the gconf keys to "sensible-audiosink" when they aren't set.
marking it as a dupe of bug #143659 because they speak about the same issue but bug #143659 is a bit more general as it speaks about [audio/video][src/sink] *** This bug has been marked as a duplicate of 143659 ***
I don't agree with merging of these bugs. Bug #143659 is about defaults at build time. This bug is about dynamically guessing the correct output sinks depending on the currently running audio daemons for example, or whether the user booted with a 2.4 kernel and OSS modules, or with a 2.6 kernel, ALSA-enabled. Please re-merge the bugs if you disagree.
*** Bug 164562 has been marked as a duplicate of this bug. ***
Hi, we now have a gconfaudiosink and a autoaudiosink in CVS. The gconfaudiosink wraps the GConf keys. The idea is that the default value will be autoaudiosink sometime soon. Autoaudiosink tries all available audiosinks in order of their rank (currently: alsa, oss). This works for almost all cases, except the soundservers. The idea for those is to add an interface of some sort that we can call in the NULL element state to see if the soundserver is running. If so, we use that, else, we go to next. So the algorhythm is: audiosinks = get_by_category ("Sink/Audio").order_by_rank for try in audiosinks; do if try.is_sound_server; then if try.sound_server_is_running; then if try.set_state (READY); then return try fi fi fi done for try in audiosinks; do if !try.is_sound_server; then if try.set_state (READY); then return try fi fi done That piece of logic hasn't been implemented yet. Once that's done, I consider this bug fixed.
Oh, also, if soundserver-specific environment variables are set (e.g. ESPEAKER for esound) or if there's some other indication to assume the user really wants to use that soundserver, then is_running returns TRUE even though it may not be running. This will not cover all cases, but will be good enough as a first try.
(While I think the autosinks are great, I did not fully catch why it's needed to make a distinction for sound daemons: wouldn't a higher score be enough? I'm just being curious.)
Hm, OK, there's a reason for that. A default system has a bunch of sounddaemons installed: esd, polyp, sometimes artsd (KDE). If GNOME is running, I don't want to start artsd, and the other way around. Therefore, we should only start it *if it is set up to start*. Now, we cannot detect that. Because a user could theoretically setup artsd to use esd, or something creepy with polypaudio in GNOME, so who knows. Therefore, we only say an audiosink is preferred if it is explicitely set to run (e.g. for esd by setting ESPEAKER for remote sound) or if it is running already. Within those boundaries, it's - again - rank-based. Sound-servers are always preferred over native sound. Native sound will be used if no soundserver is setup (i.e. like how Fedora does it), again rank-based.
The above has been implemented. Closing this bug.