Mixer applet doesn't unmute automatically

Bug #4502 reported by OrangeJon
6
Affects Status Importance Assigned to Milestone
gnome-applets (Ubuntu)
Fix Released
Medium
Ubuntu Desktop Bugs

Bug Description

In the GNOME Volume Control, dragging the sliders down to zero makes the "mute" symbol appear, which is fair enough. But then dragging the sliders back up doesn't unmute the sound, which can be quite confusing!

It's particularly annoying when you're trying to work out why you're not getting any sound (an all-to-common occurence under linux, alas) and then it eventually just turns out to be this!

Revision history for this message
OrangeJon (mail-orangejon) wrote :

Using version 2.12.0 (latest in Breezy)

Revision history for this message
Sitsofe Wheeler (sitsofe) wrote :

Alas no steps to reproduce this were included in the original bug so I shall offer some that I think reproduce this problem:

Steps to reproduce:
1. Press the right mouse button over the volume applet.
2. Make sure Mute is ticked.
3. Left click the volume applet and drag the slider upwards to the highest position.

Expected result:
Sound to become unmuted.

Actual result:
Sound remains muted.

OrangeJon: Does the above accurately describe the problem you are seeing?

Changed in gnome-media:
assignee: nobody → gnome
Revision history for this message
OrangeJon (mail-orangejon) wrote :

Sorry, I should have been more specific...

Steps to reproduce:
1. Double click the volume control icon to make the mixer window appear.
2. Drag any slider (master, PCM, etc.) down to zero. The channel becomes muted (the "mute" symbol appears below the slider).
3. Drag the slider back up from the zero position.

Expected result:
Sound to become unmuted.

Actual result:
Sound remains muted.

Revision history for this message
OrangeJon (mail-orangejon) wrote :

In fact, what I mean is that when the channel starts off unmuted, I expect it to become unmuted again when I move it back up from the zero position. If the channel were to start off muted and I drag it to zero and back up again, it is more debatable as to whether it should become unmuted (although I think it should).

Revision history for this message
Emmet Hikory (persia) wrote :

In addition to the two reports above, this can be reproduced with gnome-media 2.13.92-0ubuntu1 on AMD64.

Changed in gnome-media:
status: Unconfirmed → Confirmed
Revision history for this message
Og Maciel (ogmaciel) wrote :

The following worked for me:

1. Click with the left button of the mouse on the volume applet and drag the volume slider all the way down; volume is muted with respective graphical change;
2. Slide the volume back up and the volume is unmutted as expected;

Then, I tried a different approach:

1. Click with the right button of the mouse on the applet, and select the Mute option; volume is muted with respective graphical change;
2. Now, with the left button, you cannot move the volume slider for it is locked in place... I believe that the volume should be unmutted if the slider is moved upwards;
3. Right-clicking on the applet and unchecking the Mute option made everything go back to normal.

To finish the triage, I then tried the last scenario here presented:

1. Double click the volume control icon to make the mixer window appear.
2. Drag any slider (master, PCM, etc.) down to zero. The channel becomes muted (the "mute" symbol appears below the slider).
3. Drag the slider back up from the zero position.

Everything worked as it should...

Am running Ubuntu Dapper (latest) with gnome-media 2.13.92-0ubuntu1 on AMD64 as well.

Revision history for this message
Emmet Hikory (persia) wrote :

My results now match the success above. The only change to the system that seems sound-related between my first test and now is the upgrade to alsa-utils 1.0.10-1ubuntu7 and a power cycle, although I don't see anything in the changelog that would indicate this fixed anything.

Revision history for this message
OrangeJon (mail-orangejon) wrote :

Interesting... If I have a single copy of the mixer applet loaded, dragging any slider to zero does *not* display the mute symbol. If I have multiple copies loaded (as often happens on multiple desktops), the mute displays the "sticky" behaviour I described above (on all copies).

Sorry for not spotting this earlier...

Revision history for this message
Emmet Hikory (persia) wrote :

I think I found my reproduction as well: if the volume control is open on the same screen, the mute lock behavior works. If the volume control is closed, normal behavior is restored. Note also that the volume is set to maximum when unmuted after the volume control is closed.

Revision history for this message
Sebastien Bacher (seb128) wrote :

The bug is not clear after all those comments. Could you describe your issue clearly again (ie: what you do, what happens, what you would expect)?

Revision history for this message
Emmet Hikory (persia) wrote :

    The specific issue is that for some states of the volume control applet, it is possible to mute the audio using the volume slider in such a way that it cannot be unmuted using the volume slider. This is annoying because the user cannot undo the action performed by using the apparently reversible tool with which the action was performed.

    The bug appears to be specifically related to irregular behaviour when multiple tools are simultaneously attempting to control the audio volume, and so it is perhaps a "Well, don't do that then" sort of thing, but is at least confusing.

To reproduce:

Open at least two volume controls (either the volume control applet and the volume control, or the volume control applet on two desktops).

Using the slider in the applet, reduce to zero volume.

Using the slider in the applet, increase the volume.

Expected Result:

    When the volume is decreased to 0, the icon is changed to the mute icon, the applet menu shows mute checked, and the output channel is muted.

    When the volume is increased, the icon is changed to the the sound icon (with the appropriate number of curves), and the output channel is unmuted.

Actual Result for volume control applet + volume control:

    When the volume is decreased to 0, the icon is changed to the mute icon, the applet menu shows mute checked, the volume is locked at max, and the channel is muted.

    If output is unmuted, it does so at maximum volume. The volume cannot be increased, as the mute locks the slider.

Actual Result for volume control applet only:

    When the volume is decreased to 0, the icon is changed to the mute icon, the applet menu shows mute checked, and the output channel is not muted (although 0 volume is normally silent).

    When the volume is increased, the icon is changed to the the sound icon (with the appropriate number of curves), and there is no change in the mute status of the channel (never muted).

    If "Mute" is selected from the menu, the icon is changed to the mute icon, the applet menu shows mute checked, the volume is locked at max, and the channel is muted. In this case also, unmuting will restore at maximum volume, regardless of the volume when muting.

    Please note that my Volume Control is labeled Volume Control (alsa mixer), if this makes a difference. Note also that the maximum volume locking is not important for this bug, although I suspect they may have the same fix.

Revision history for this message
Sebastien Bacher (seb128) wrote :

I've already opened some bugs upstream about the mixer applet, your issue is a combinaison of them:
http://bugzilla.gnome.org/show_bug.cgi?id=331763
http://bugzilla.gnome.org/show_bug.cgi?id=331764
http://bugzilla.gnome.org/show_bug.cgi?id=331765

Thank you for the efforts on that. Just a note, could you try to make short descriptions? One page of text tends to decourage people reading your bugs. Look on the bugzilla pages I pointed to have an example of short description which is enough to understand the issue

Changed in gnome-applets:
assignee: gnome → desktop-bugs
Revision history for this message
Emmet Hikory (persia) wrote :

All but one of the many issues raised have been solved upstream. The remaining issue has been moved to bug #42853 for ease of analysis.

Changed in gnome-applets:
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.