GNOME Bugzilla – Bug 329112
Sound device selection
Last modified: 2007-02-15 19:00:21 UTC
The only current possibility to select a different ALSA sound device is by specifying a custom pipeline in the multimedia systems selector from gnome-media. We can't expect normal users to first look at /proc/asound/cards, getting the right card number, and writing alsasink device=hw:X,Y in the text entry. Furthermore it's only possible to specify one global default sound device even though an increasing number of users use e.g. a usb headset for audio/video conferencing and the on-board sound card for normal sound playback. I propose to add a new devices tab to the sound capplet with comboboxes to choose the preferred sound device for sound events, music/movies, resp. audio/video conferencing. The sound device list should be retrieved via HAL. Patch will follow soon. This bug is part of my sound configuration patches to allow sane graphical selection of sound cards in GNOME.
Created attachment 58343 [details] [review] Patch to add sound device selection to the sound capplet First attempt to add sane sound device selection via HAL. Accelerator keys are missing in the UI; we should probably first ask for UI review anyway. Obviously GNOME 2.15/2.16 material.
Created attachment 58344 [details] Screenshot of sound applet with applied patch
This looks ok to me, although since we are about to hit UI freeze, I'd like other people's opinions before committing it. As per the code, do we really need to depend on gstreamer-0.10? The configure.in checks the GST version, and, AFAIK, we should be ok to compile with both versions.
The attached patch requires gstreamer modifications (see dependent bug 329106 and bug 329107 ) which very probably don't work as is with gstreamer 0.8. I didn't expect the patch to be considered for GNOME 2.14, and I thought it should be a non-issue to let GNOME 2.15/2.16 depend on gstreamer 0.10.
ok, if it's not for 2.14, let's wait and will commit it as soon as we branch.
*** Bug 305907 has been marked as a duplicate of this bug. ***
I'd be happy to support the "Music/Video" one in Totem. However: - the video capture item shouldn't be there, this should just be the sound capplet, otherwise I would want to see hue/brightness/contrast support there as well - The video conferencing options should get buy-in from Damien for Ekiga - We shouldn't see that many options if there's only one soundcard, and there should be an option to select the same soundcard for all the settings - How is multi-channel setup handled? - What other work is needed for applications to handle changes in those settings on the fly?
*** Bug 172594 has been marked as a duplicate of this bug. ***
Please also see: http://mail.gnome.org/archives/utopia-list/2005-July/msg00001.html especially "What do we want to do when a new soundcard is plugged in?"
Bug 172594 contains a lot of comentary and usecase discussions. Should probably be reviewed by the person(s) tackling this issue.
(In reply to comment #7) > I'd be happy to support the "Music/Video" one in Totem. Thanks for your comments. > However: > - the video capture item shouldn't be there, this should just be the sound > capplet, otherwise I would want to see hue/brightness/contrast support there as > well IMO it makes sense to have a combined sound & video capplet, a separate video capplet would be exactly the contrary to the proposals in http://live.gnome.org/PreferencesRevisited Maybe a feasible compromise would be to add a separate "Video" tab to the capplet where of course hue/brightness/contrast sliders would make sense. I assume it should be possible to control h/b/c with a gstreamer plugin, so we can use the already existing gconfvideosink key. > - The video conferencing options should get buy-in from Damien for Ekiga Yes, definitively. It may not be that easy, though, as Ekiga doesn't use GStreamer. It should be possible to extract the HAL UDI from GStreamer's GConf keys and then pass the ALSA device number on to opal. Does that make sense or does that seem too impure? If it'd be ok, does Damien have time to implement this or should I give it a try? > - We shouldn't see that many options if there's only one soundcard, and there > should be an option to select the same soundcard for all the settings Generally, I agree. It may not be that easy to decide when to display the tab, though, as not only HAL devices are shown (to not lock out non-ALSA/HAL users). > - How is multi-channel setup handled? Sorry, I don't know how this should be handled, do you have any suggestions? > - What other work is needed for applications to handle changes in those > settings on the fly? AFAICT, it theoretically should work as it is built upon the existing GConf GStreamer plugins which support on the fly switching. However, in practice it didn't work for me, I got hangs and crashes (with both, totem and gst-launch). What surely doesn't work yet on the fly, that is automatically switching between preferred sound device and fallback when the preferred sound device gets plugged out or in. This shouldn't be hard to implement, though, I just need to add HAL notification support to the HAL GStreamer plugins. (In reply to comment #9) > Please also see: > http://mail.gnome.org/archives/utopia-list/2005-July/msg00001.html > especially "What do we want to do when a new soundcard is plugged in?" I agree, that we probably want one daemon (preferrably gnome-volume-manager) as a policy manager with possible user interactions. IMO this should be built on top of my proposal, i.e. let gnome-volume-manager just change the GConf key if appropriate. I haven't planned to work on that at the moment.
> > However: > > - the video capture item shouldn't be there, this should just be the sound > > capplet, otherwise I would want to see hue/brightness/contrast support there as > > well > > IMO it makes sense to have a combined sound & video capplet, a separate video > capplet would be exactly the contrary to the proposals in > http://live.gnome.org/PreferencesRevisited > Maybe a feasible compromise would be to add a separate "Video" tab to the > capplet where of course hue/brightness/contrast sliders would make sense. I > assume it should be possible to control h/b/c with a gstreamer plugin, so we > can use the already existing gconfvideosink key. Totem uses some private GConf keys for that right now. I'm not 100% sure how to handle it, especially when only one Xv port is available, as trying to change this configuration in Totem would mean that the "preview" wouldn't be available in the capplet, and at the same time, you would want a preview if Totem (or another video application) wasn't available. > > - The video conferencing options should get buy-in from Damien for Ekiga > > Yes, definitively. It may not be that easy, though, as Ekiga doesn't use > GStreamer. It should be possible to extract the HAL UDI from GStreamer's GConf > keys and then pass the ALSA device number on to opal. Does that make sense or > does that seem too impure? If it'd be ok, does Damien have time to implement > this or should I give it a try? That sounds like we should question how the preferences are stored in GConf then. I'd like to be able to use this configuration with xine-lib as well. > > - We shouldn't see that many options if there's only one soundcard, and there > > should be an option to select the same soundcard for all the settings > > Generally, I agree. It may not be that easy to decide when to display the tab, > though, as not only HAL devices are shown (to not lock out non-ALSA/HAL users). Having every ALSA user have HAL installed wouldn't be much of a problem. ALSA only works on Linux, and HAL works just fine on Linux. So requiring HAL would be fine, but requiring ALSA wouldn't. > > - How is multi-channel setup handled? > > Sorry, I don't know how this should be handled, do you have any suggestions? I'm not sure how to handle this even ;) > > - What other work is needed for applications to handle changes in those > > settings on the fly? > > AFAICT, it theoretically should work as it is built upon the existing GConf > GStreamer plugins which support on the fly switching. However, in practice it > didn't work for me, I got hangs and crashes (with both, totem and gst-launch). > What surely doesn't work yet on the fly, that is automatically switching > between preferred sound device and fallback when the preferred sound device > gets plugged out or in. This shouldn't be hard to implement, though, I just > need to add HAL notification support to the HAL GStreamer plugins. I was thinking more in terms of: - do applications only monitor GConf, and act upon the change? - do we need changes to some infrastructure to make ESD handle the change? > (In reply to comment #9) > > Please also see: > > http://mail.gnome.org/archives/utopia-list/2005-July/msg00001.html > > especially "What do we want to do when a new soundcard is plugged in?" > > I agree, that we probably want one daemon (preferrably gnome-volume-manager) as > a policy manager with possible user interactions. IMO this should be built on > top of my proposal, i.e. let gnome-volume-manager just change the GConf key if > appropriate. I haven't planned to work on that at the moment. How do you want to handle missing devices? Should we fallback to the "first" soundcard when the USB card isn't available anymore?
(In reply to comment #12) > > > - The video conferencing options should get buy-in from Damien for Ekiga > > > > Yes, definitively. It may not be that easy, though, as Ekiga doesn't use > > GStreamer. It should be possible to extract the HAL UDI from GStreamer's GConf > > keys and then pass the ALSA device number on to opal. Does that make sense or > > does that seem too impure? If it'd be ok, does Damien have time to implement > > this or should I give it a try? > > That sounds like we should question how the preferences are stored in GConf > then. I'd like to be able to use this configuration with xine-lib as well. My proposal builds on top of the current implementation. Instead of setting the gconf key to alsasink it just sets the key to something like halaudiosink udi=/org/freedesktop/Hal/devices/pci_8086_27d8_alsa_playback_0_0. The UDI => ALSA mapping gets done by the proposed HAL GStreamer plugins. If I understand you correctly, you'd more be in favor of GStreamer-independent GConf keys. Then the question would be how to handle non-HAL sound devices, e.g. sound servers, custom GStreamer pipelines, custom ALSA PCM devices,... I'd still go on with assuming that most software (that need the settings) are GStreamer-based, as that's what we're aiming for, I assume. Applications which don't/can't use GStreamer like Totem/Xine and Ekiga, can still steal GStreamer's GConf keys and convert the GStreamer element string for use with their own backend fairly easily. If we aim for a GStreamer-independent solution, it should probably be GNOME-independent as well, i.e. a fd.o spec to share with other desktops. We'd have to abandon using GConf for this and it'll probably take quite some time until we reach an agreement - especially knowing that KDE will abstract the Hardware Abstraction Layer again, so we wouldn't even be able to agree on that. Therefore I aim for a GStreamer-oriented solution while allowing Totem/Xine, Ekiga, and maybe other interested applications to access these GConf keys, too. > > > - What other work is needed for applications to handle changes in those > > > settings on the fly? > > > > AFAICT, it theoretically should work as it is built upon the existing GConf > > GStreamer plugins which support on the fly switching. However, in practice it > > didn't work for me, I got hangs and crashes (with both, totem and gst-launch). > > What surely doesn't work yet on the fly, that is automatically switching > > between preferred sound device and fallback when the preferred sound device > > gets plugged out or in. This shouldn't be hard to implement, though, I just > > need to add HAL notification support to the HAL GStreamer plugins. > > I was thinking more in terms of: > - do applications only monitor GConf, and act upon the change? GStreamer-based applications shouldn't even need to monitor GConf as that's what the GConf GStreamer plugins already do. Other applications should only need to monitor GConf, yes. > - do we need changes to some infrastructure to make ESD handle the change? ESD dosn't handle multiple sound cards well at the moment, from a _very_ quick glance at the code. AFAICT it just uses the first device it can open when using ESD with ALSA. If there are ESD users with multiple sound cards, this should probably get fixed. Or maybe we should better just improve polypaudio to handle dynamic switching from GConf. > > > (In reply to comment #9) > > > Please also see: > > > http://mail.gnome.org/archives/utopia-list/2005-July/msg00001.html > > > especially "What do we want to do when a new soundcard is plugged in?" > > > > I agree, that we probably want one daemon (preferrably gnome-volume-manager) as > > a policy manager with possible user interactions. IMO this should be built on > > top of my proposal, i.e. let gnome-volume-manager just change the GConf key if > > appropriate. I haven't planned to work on that at the moment. > > How do you want to handle missing devices? Should we fallback to the "first" > soundcard when the USB card isn't available anymore? That's exactly what it does with my current proposal (the HAL GStreamer plugins fallback to system default which usually is alsasink). I could imagine some users with 3 sound cards and more with some fancy fallback scheme but I don't know whether we should really be able to handle this. And how complicated the corresponding configuration user interface would become...
(In reply to comment #13) > ESD dosn't handle multiple sound cards well at the moment, from a _very_ quick > glance at the code. AFAICT it just uses the first device it can open when using > ESD with ALSA. If there are ESD users with multiple sound cards, this should > probably get fixed. Or maybe we should better just improve polypaudio to handle > dynamic switching from GConf. some people might as well want to use jack instead. and use some sort of graphical jack routing app (or some command line tools) we may also thus need jack source and sinks
I think the GConf keys idea is a good one.
Both GStreamer patches now merged. I guess due to the freeze this patch will not go in before 2.14, but hopefully it can get merged as soon as there control center is branched.
Hi Jurg and Rodrigo, Since GStreamer 2.14 is out now could this be merged? The GStreamer parts are already in GStreamer releases, so there should be nothing 'upstream' blocking it now.
Created attachment 62127 [details] [review] Updated patch without video device selection I've updated the patch and removed the video part as that doesn't fit in the sound capplet, according to hadess. I haven't removed all traces of video support, so it could be readded if necessary.
Rodrigo, is this ready to go in now? The latest gst-plugins-good got the haldevices included so I don't think there should be anything blocking this getting merged now.
The code looks good to me, so please commit and we'll deal with bugs as they show up. Better to have this in HEAD ASAP so that we have time to make changes, if problems arise.
Committed to HEAD.
Created attachment 64867 [details] [review] Proposed patch 2006-05-05 Dennis Cranston <dennis_cranston@yahoo.com> * sound-properties.glade: Small HIG fixes (label capitalization and mnemonics).
I just attached a small patch to fix the label capitalization and add mnemonics to the new UI.
Jürg, does it look ok to you? It does to me
Totally forgot about the keyboard handling, thanks. It looks basically fine but the mnemonics of the test buttons are problematic as they all point to the ´T´. I don't know an easy solution, though, as there are more test buttons than different characters in "Test"... How does GTK+ handle multiple identical mnemonics, cycling?
> How does GTK+ handle multiple identical mnemonics, cycling? Yes, GTK+ cycles through widgets with the same mnemonic.
Hi all Interesting read. I myself think it would be better if applications opened a "gnomesink" with a parameter "application_id" of value, e.g. "org.gnome.Rhythmbox". You could then choose ALSA device profiles on a per-application basis, through the audio capplet. It would also be possible to hook this into polyp with the application ID and allow you to control volumes of applications independently through the mixer applet, much like OS X.
Sorry for the spam... adding CC.
Just noticed this is something that was requested for gstreamer-properties aswell a few times. Bug 341983 attempts to create basicly the same as here just with gstreamer-properties and might be worth to know about. (Sidenote, it will now also be adjusted to use HAL, not gst device property probing as the prop. patch does) To me it seems to be a generic question of responsibility as where to implement device configuration overall in the desktop system and looks like some diagram work or discussion (not here) could help to solve this. (GStreamer? gst-properties gconf keys? Custom pipelines? ALSA, OSS, ESD? Video in/out devices? Advanced device settings?) A specific location and way to store/retrieve device selection and advanced device configuration per profile (Audio, Video, Conference, ...) using a "gnome-multimedia-properties" capplet that gets it's device info from HAL. If GStreamer is installed, it should also setup the pipelines with correct devices (all stored in gconf atm.). Creating a "Multimedia System Selector" capplet like gstreamer-properties might be the better way to go overall?
*** Bug 354951 has been marked as a duplicate of this bug. ***
Shouldn't this be closed as fixed now?
Closing this. Please file new bugs if there are any issues with this functionality.