GNOME Bugzilla – Bug 173035
Volume up/down keys should affect default channel of the applet
Last modified: 2007-03-24 21:16:21 UTC
The volume control applet lets the user choose (right click -> Preferences) which channel to control when one left-clicks the applet. It would be nice to have the volume keybindings affecting this channel. The problem I faced is that my laptop has different volume controls for the speaker and the headphones (ie. the main volume control doesn't affect the headphones). So I cannot control the volume with keybindings when I connect the laptop to external speakers through the headphone jack. Setting the applet channel to PCM, I can control both headphones and speaker, but this doesnt affect the keybindings. Problem with the suggested improvement: the user can have several volume applets, each controlling a different channel. There are several other possible solutions: - a preference for the volume keybinding so that one can choose which channel to control - adding the possibility of locking together some channels in gnome-volume-control so that changing one volume will change the others (so I would lock together main and headphones) - Other information:
Hi, I see the problem, but I'm willing to be OK with that for now. Someone made a patch for the panel applet to control multiple tracks, I'd like to apply that first, and then work on this bug to make the two control the same. It makes a lot of sense; or rather, it's stupid for the keybindings to not follow the applet selection, it's the right thing [tm] in 99,99% of the cases.
Created attachment 47556 [details] [review] patch This patch does exactly that. Gnome-applets uses a special panel-applet API to get the keys, btw, so I may be doing something wrong there. It works for me, however, it nicely changes the same tracks that we change, too. And since we timeout after a few seconds, we will update (with a small lag) the controlled tracks when the applet changes those, too. Please comment (will CC some maintainers).
Thanks for tackling this, I'm marking #168979 as a dupe. I don't think the approach of locking different tracks together is very elegant, because they can have very different scales. If one raises the volume, one can saturate, or in the other case become mute. I'd prefer keeping only one track which has the keyboard focus, and reflecting this with a checkbox «this track is controlled by the keyboard» in the panel applet. Setting the focus to PCM will affect every audio output, headhones and speakers, and is generally the Right Thing.
*** Bug 168979 has been marked as a duplicate of this bug. ***
I'd like to understand what happens when there are 2 volume applets (2 soundcards, 1 soundcard and different channels, whatever).
Bastien: we pick the settings from the first. This may not be ideal. Gabriel: we scale per track, so that's no issue. There's still the issue of some experts wanting to control different tracks using the keyboard keys than the applet. I have no solution for that yet. Adding more options to the applet is definitely not the way. The applet normally controls only one track (master), and sometimes two (e.g. headphone/speakers, if there is no master). In all those cases, it makes sense to control all those with the keybindings, too. That's the use case. Not ideal, but works for >99% of the cases, and probably pretty much all users except a very select expert few.
There's another use for binding 2 channels together: Bind the PCM and the 'Master' channels together. Normally, if you set PCM to 100% and just use master to control the volume then it's sort of annoying. 0% master is mute and 1% master is quite loud when PCM is at 100%. As a solution to this, for a number of years I've been using a separate daemon that listens on /dev/input/event* for volume control keypresses and moves the PCM and the master channels together. On one end you get 100%/100% for full volume, and on the other end you get 1%/1% which is quite quiet. Having this functionality in GNOME will let me kill off this background process and use the gnome keybindings for adjusting my volume.
Some additional thoughts: The patch looking through the panel gconf tree for a valid instance of the mixer applet is more than just a little bit evil. It would be nice if there was a global key for "prefered mixer channels" or whatever -- configured through the gstreamer-properties dialog -- useable by the applet and the keybindings. At this point you could even eliminate the applet's preference dialog box and have it pop up the gstreamer properties box open to the correct pane. This also has the advantage of not having to have the mixer applet on the panel in order for the hotkeys to work the way that you want them to (since, really, if you've decided that you want to use hotkeys to change the volume, then you probably don't want the mixer applet). Just my 2¢.
Ryan: it doesn't need the actual instance; it just looks at the keys. If those are missing, it'll use the master track by default, which is what the keybindings currently do. Having system-keys instead of stealing someone else's keys sounds like the right way, though. Even the gnome-volume-control could use those keys as default. we could share the preferences window of the applets for that in $libexecdir, maybe.
Bastien suggested to have the preferences for the keybindings (and applet, shared) live in the sound capplet. I'm not totally sure how this will work yet in the end, since a user could have multiple applets control multiple cards, so you may still need an applet-specific configuration in addition to the desktop-wide default for possibly one applet and the keybindings, but we'll figure something out at some point. We should not hold this patch until that's done, though, since this (imo) is already an improvement.
The patch doesn't seem to handle: - multiple volume applets - no volume applet - looking through GConf seems "random" (create one applet, then a second one, remove the first one, where does it look for the track to use?) - ALSA backend doesn't use the same data So I'd rather see this setting in the sound capplet
I'm told it *does* handle having no volume applet, although I'm not sure what would happen when there's config data in GConf, but no volume applet.
*** Bug 319004 has been marked as a duplicate of this bug. ***
*** Bug 172736 has been marked as a duplicate of this bug. ***
Hey Bastien, so... Putting this in the sound capplet sounds like a good idea; however, that does not address the issue of wanting multiple applets, because then what would the second applet control? Or should the applet default to what's in the capplet and be allowed to be refined through its own preferences? I'm willing to do the work for this bug, because it keeps annoying me lightly (including the ALSA backend, I indeed didn't do that yet), but I don't have the complete picture ready yet. So, in short, we have three "applications": - volume control - volume applet - acme/keybindings There's only one instance of the keybindings, it controls one or multiple tracks of a single soundcard. The applet can control one or multiple tracks on one soundcard, but different applets may be active at a time, each controlling the same or different soundcards. Also, multiple volume controls can be open, each controlling one soundcard. This is what's *technically* possible, it may not be ideal usability-wise. So, how would you guys like to see this done in practice? We could use the capplet as central configuration for the default sound device, and would the applet/control then default to that device but allow to be changed in their respective preferences? Also, should audio in/out default to the same device? What about people that want one soundcard for music/video but another for games (or something wacky like that)? Cheers, Ronald
*** Bug 156330 has been marked as a duplicate of this bug. ***
Summmary of IRC discussion, for my own sanity: step #1: add preferences for track and soundcard (#305907) to capplet, make acma conform. This is easy. step #2: at some point, "merge" applet preferences with capplet preferences in a way, so that applet -> preferences works with the capplet or something like that (which will make it a bit more discoverable and logical for novice users). All this without losing the multiple-applet functionality.
With any released version of GNOME, is it possible to specify anywhere (UI or no) which sound card is to be affected by multimedia keys? If not, I recommend increasing the "severity" of this bug, since it basically renders multimedia keys useless for a non-zero portion of GNOME's users (maybe 0.5%?). Even worse, the multimedia keys give visual feedback which does not reflect reality.
(In reply to comment #18) [...] > keys useless for a non-zero portion of GNOME's users (maybe 0.5%?). Even worse, > the multimedia keys give visual feedback which does not reflect reality. I'd think 0.5% is really a understatement. This may actually be the case for most soundcards. I own myself an onoboard soundcard and a PCI soundcard with quite common chipsets (C-Media and ICE), and both don't use the default channel (or whatever is the messure currently) for real volume control. The ICE chipset even uses two channels one for the left and one for rhe right speaker, this is easy to configure with the mixer applet, but as said before impossible with multimedia keys.
It should probably use the "default" soundcard in the capplet changes, as mentioned in this other bug. Not sure what to do when the "sound effects" and "video/music playback" cards are different though...
Created attachment 59061 [details] [review] Adds a GConf value to define the mixer device This annoyed me to no end. I have attached a small patch that i wrote which adds a GConf value that specifies the mixer element/device that you want the multimedia keys to control. I agree with the above post that it should be a graphical selection but it's tricky to say where that graphical element should reside. For now, here is something that works :). Jonathan
*** Bug 331410 has been marked as a duplicate of this bug. ***
I'm not sure what the status is here, but as of 2.14 final (on Ubuntu Dapper) the acme keys control the "headphone" channel (which doesn't actually control the headphones, but thats another issue I suppose). Previously (in 2.13.90 I believe, a few updates ago) it controlled PCM.
Note that as #331410 mentions, the keys control the first listed item which is 'Headphone' in my case.
(In reply to comment #24) > Note that as #331410 mentions, the keys control the first listed item which is > 'Headphone' in my case. > If this is really the case, that won't work, at least in my case, because I have to control 2 channels (left+right are seperate on my soundcard) at the same time.
*** Bug 337108 has been marked as a duplicate of this bug. ***
So... what is the situation on this one? Just found a duplicate of this, and I'm seeing this too. Changing versions to the most recent one, and upping the severity from enhancement to normal - since this actually renders the keyboard shortcuts useless for many users.
Created attachment 67088 [details] a mockup It seems to me that we should have a default set of channels defined in control-center using a similar widget to the applet's existing channel selector. New applets would then default to using the global setting, but still be overrideable. Each of these dialogs should have a button that will open one of the other dialogs that involve settings (ie. the applet should be able to open the global prefs; the global prefs should be able to open the keybinding prefs). Apologies for the poor quality of my mockup.
*** Bug 342000 has been marked as a duplicate of this bug. ***
I believe this bug is the same that is causing me trouble in my Ubuntu Dapper install. I first noticed it while in a college class taking notes. I had gaim open and had muted my sound by hitting a fn+f2 key and my volume showed muted. But, apparently that wasn't entirely true, it seems the sound in Gaim for recieved IM was still playing through the PCM channel, so in the middle of a lecture I had a couple of annoying IM sounds go off, quite loud. Now, whenever I want to make sure my sound is completely muted, I have to mute the Master channel which I can do by keyboard, and go into the volume applet and mute the PCM channel too...just in case. The Master mutes most everything, Rhythmbox for instance. I'd think there should be some way to have the keyboard command control more than one channel's volume, kind of link them up, especially for mute. A Mute keyboard command should mute all available channels, or the Master volume should be the "cut-off" and if that's muted then nothing else can play. I'm no developer, just an end user, but that's my 0.02 cents from my perspective. Keep up the great work.
On my notebook, Master and Headphones are independent. I usually end up with sound blasting through the headphones with the buttons on the side of the notebook having no effect (only Master is affected by these key bindings).
Some further info I'm using control-center-2.15.4. While keybindings only control the Master channel (and not the Headphones channel), the Volume Applet (aka mixer_applet2) on the gnome-panel does control BOTH channels in a locked fashion. A minimal fix should be to copy (or use) this feature.
*** Bug 345224 has been marked as a duplicate of this bug. ***
*** Bug 388461 has been marked as a duplicate of this bug. ***
*** Bug 391836 has been marked as a duplicate of this bug. ***
Created attachment 79756 [details] [review] Patch to implement the sound-capplet and keybindings part
Patch looks generally good - let's get this in got 2.18!
Patch committed
The new control center setting looks very promising, but for some reason, the keyboard shortcut still doesn't work properly for me. The new indicator look quite pretty however! My system is comprised of two sound cards. I can see how allowing people to select multiple tracks is useful. Even though I don't need it, I would like to point out that you can't select multiple tracks across multiple sound cards. I would also note that gnome doesn't gracefully handle removable sound cards (like a USB sound card you plug in after you log in), but that rant is worth saving for another bug ;) I'm using 2.17.92, and both the control center setting and the track for the volume control applet are being ignored. The keyboard shortcut always changes the master track on the first soundcard. In my case, just setting the master track on the default ALSA plug would have been enough. As for the importance of the bug, is one of the oldest things buggin me in gnome. I have multimedia keys on two keyboards as well as two remotes with buttons for volume control. It would be nice if they worked with my setup. Anyhow, alsamixer + xbindkeys here I come!
Ok, so the bug is fixed in gnome 2.18. In the meantime, for those of us who have gnome 2.16 (last version in fedora repositories is gnome 2.16.3), I've thought in a workarround. In comment #24 we can read: > > Note that as #331410 mentions, the keys control the first listed item and in bug #331410: > > "Master" or the first channel is always the one that is changed As we have seen in this thread, in gnome 2.16 we can't change the channel used by keybindings. But, CAN WE CHANGE THE CHANNEL THAT IS THE FIRST ONE? I mean, is it possibe to change the alsa configuration, altering the order of the channels, to make PCM to be the first channel? That is not clean, but would work. In my case, the channel order is the following: 1 Master 2 Master M 3 PCM 4 Surround ... "Master" is the first channel, so keybinding app uses "Master", that has no effect (PCM is the channel that controls the volume). But, if we alter the order of the channels, and make "PCM" the first channel: 1 PCM 2 Master 3 Master M 4 Surround ... then the keybinding app should use the "PCM" channel, since it's the first channel now. Is that possible? Can the channel order be changed? How can we do that? I've been browsing some pages on alsa configuration, but I can't find the exact way to change the order. Alsa config files are too complex for me. Anyone can give some help? Thanks