GNOME Bugzilla – Bug 164925
Mute and volume=0 status are confusing
Last modified: 2015-09-26 04:53:05 UTC
Currently If you set the volume to the lowest level you get the mute icon If you set the volume a bit higher you get the volume-0 icon volume-0 should be used for the lowest level and mute only when mute is applied
This is the expected behaviour. It is to work around the fact that some soundcards don't have Mute states according to ALSA. For some cards, ALSA sets the volume to 0 instead of muting, as a result, we use the mute icon.
Created attachment 36383 [details] [review] Patch solving problem in comment 1
Sorry the above comment should not say comment 1 but the original bug. Davyd, would you mind looking at the patch I made? I think it's behavior is better then the current implementation. It works as expected with a soundcard with mute so state icon ------------------- mute mute vol=0 volume_0 0<vol<1/3 volume_low 1/3<=vol<2/3 volume-med 2/3<=vol<=1 volume-high For a card without mute (I think because I don't have one) state icon ------------------- mute volume_0 vol=0 volume_0 0<vol<1/3 volume_low 1/3<=vol<2/3 volume-med 2/3<=vol<=1 volume-high I think this is behavior as expected. If the card does not support mute, you don't have a mute state, if it does it supports it the way you expect it. BTW Do you have any idea what the percentage of cards is that does not support mute? I hope you don't mind I reopen the bug. So you can take a look at the patch
As I understand it, it's a widespread problem. For the moment, our current functionality is consistant across all cards and therefore preferable. As I indicated earlier, this was a concious design decision by the author and GNOME Media team.
It's not just hardware. Most apps *know* that mute doesn't exist, and therefore they simply set volume to zero to mute. For OSS, mute doesn't even exist. The current behaviour works around that, and I think that's expected. I can add a check that it doesn't mute if you drag the slider to zero manually, but in any other case, the current hebaviour is right...
OK, thanks for explaining the issue. Can you then also add a check that if I do it via the keyboard shortcut?? Furthermore the volume_0 is now used for the first quarter of the volume which is in my opinion incorrect. I suggest to use that icon only when you set the volume to zero by the slider or the keyboard shortcut
You mean the multimedia keys? That's done via control-center's keybindings. I didn't look at those yet, but I know they're imperfect. They're on the list for improvement in this field...
Yes, I mean those ones
Just another idea that hit me right now, which I think can solve my initial gripe. Can't the GNOME desktop get identical behavior for all apps by using mute and volume settings in gconf. Compliant applications just should write the volume/mute settings in gconf. A small volume daemon would then change the real volume.
http://bugzilla.gnome.org/show_bug.cgi?id=164452 That bug discusses the multimedia key things. I'll hopefully work on that sometime soon... As for your suggestion, GConf would only help accross GNOME. We're really talking about a system setting here, and having an intermediate state in GConf only complicates stuff. GStreamer already provides a nice intermediate station to unify all different APIs, I think that's enough wrapping...
As Ronald stated. GConf is _not_ the solution. The solution is either something in GStreamer, or making the sound APIs at kernel level suck less. Of course, I would argue that our current action is correct. Displaying the mute icon when the volume is 0 is linguistically correct. After all if it's making no sound, it is mute.
Reopening this bug as I still feel the current implementation is not right. See for example the following use case: Let's say that the current volume is zero 1. mixer-applet shows muted icon 2. User thinks: hey no audio 3. he hits the mute/unmute key on his keyboard 4. mixer still shows muted icon!! 5. user thinks why nothing is happening?? Is my keyboard broken?? If in step 4 the volume zero icon was shown the user would have noticed that at least something happened and give him the clue that the volume is too low. I understand the problem that not all cards have a mute and that consequently the mixer has to be set to zero if you want to mute. gst_mixer of gstreamer provides the interface to mute. So if an app is using gstreamer (and luckily more and more do) muting will always work because gstreamer is abstracting the fact that a sound card does not have a mute. The apps that do not use gstreamer and are using a soundcard that does not support mute will simply show a volume zero when mute is used in that app. It's not 100% correct behavior, but it is close because the mixer just indicates that the volume is zero and therefore there is no sound. Do you agree on this?
*** Bug 331764 has been marked as a duplicate of this bug. ***
*** Bug 333438 has been marked as a duplicate of this bug. ***
I agree with #12.
The problem in thinking that gst abstracts mute is that it's not true (see 170575). :-).
There should be no such thing as a volume-0 icon. What really needs to happen, is that the volume level prior to "mute" needs to be saved and restored. Alternatively, mute needs to be abstracted, and ((volume == 0) == mute) needs to be true, and when the user presses the mute key to unumte, the volume is increased to 3% or 6% or something like that. See the behavior in Mac OS X. It has the behavior that I believe we desire here, and allows for dealing with cards that don't support mute. The volume level icons that should be used, are audio-volume-{low,medium,high,muted}.
We do all that, except the volume=0 -> unmute should lead to volume=3% or 6%, I can implement that (although I would probably go for 50% or so...? Dunno really)
(In reply to comment #18) > We do all that, except the volume=0 -> unmute should lead to volume=3% or 6%, I > can implement that (although I would probably go for 50% or so...? Dunno > really) (comments made without perusing source) Is it that much harder to store the volume before the mute and restoring it afterwards? IMO, you'll never satisfy everyone if you restore to an arbitrarily chosen volume percentage. You'll always end up having to adjust the volume up or down after you unmute - a two step process.
GstAlsa hides the fact that some device don't have mute inside the mixer code. My patch in bug 478485 removes the volume == 0 -> mute code. Now mute is only activated if the volume is really at 0.