I'm encountering this problem as well in Volume Applet 2.20.0. When scrolling the volume from 0 to 100%, I'll typically see between 2 and 10 of these bogus "mutes".

I also noticed that when in this not-really-muted state, the tooltip will change to say "Master: muted" and the context menu has "Mute" checked. Unchecking it fixes the icon and tooltip, but has no effect on the sound (because it wasn't really muted to begin with).

Happens to me too on two of my laptops. Using the latest rawhide updates.
No idea how to provide more information or debug this though.

*** Bug 505568 has been marked as a duplicate of this bug. ***

Confirming because of the duplicate.

A very similar bug has been reported by Debian users, it seems to primarily hit snd-hda-intel users, but there's also one report of it happening with the snd-powermac module.

One submitter described it like this:

"I have been experiencing the same problem, but more recently it became
worse: mixer_applet2 can randomly change the volume to any value (for
real, not just display as the mute problem). For example, I'm at 76%,
use the up key and expect to get 80%, when instead I get 25% (it's
random, could be anything else). It happens randomly but often enough that
if I keep the Up key with auto-repeat, I can see the volume cycling through
various values.

Two possible workarounds:

- I take the binary file /usr/lib/gnome-applet/mixer_applet2 from the etch
  package (version 2.14.3-4) and simply use it to overwrite the current
  one (version 2.20.1-3).  (I then kill the mixer_applet2 process so gnome
  asks to restart it).
  Hop, everything is working fine again:
  No random mute display, no random mistake in volume value.

- else, changing the applet preferences and using the OSS emulation API
  instead of native ALSA API for the card makes it work fine too (no false
  mute, no volume mistake).

First method shows there's something that changed in mixer_applet2 between
2.14.3-4 and 2.20.1-3 that should be investigated, and not just leave it to
a driver bug, considering that alsamixer always behaves correctly."

For all the reports, see the downstream bug at http://bugs.debian.org/451203

Hello,
I'm the submitter of the last "downstream comment" reported by Sven Arvidsson and I have to correct what I said earlier, because it was half wrong (version 2.14.3-4 has problems too). Tell me if I should report it in a separate bug. Here's what I added later on the downstream comment:


I did more testings, including with an other card (usb-audio, usb code
046d:0a01, it's a Headset sound card type from Logitech).

Sadly I have to correct my previous report. Altough I didn't notice it,
I also get volume problems with the 2.14.3-4, it will just never display
the volume as a false mute.

Still on hda-intel the behavior on 2.14.3-4 is like this:
Randomly, when changing the master volume (and checking with an alsamixer also 
running), the left volume channel drops to zero, while the right volume
stays correct. On the next change, the two channels are averaged. So after
some up key I got 75% -> 79% but the left channel dropped to zero in
alsamixer. Then I decreased it, the new value was 35% (79/2 -4)
for the two channels. Actual values from test.

With 2.20.1-3, the behavior is a bit different, I never see the left channel
dropping to zero, but about the same happens.
One test: I did up with 28% and it dropped to 16%. I can assume it's
increased first and then divided by 2 ((28+4)/2). Other try: 59% up, I get
31% ((59+4)/2). There's also the random false mute display, but I can't
find it linked with when the volume gets wrong.

Now with the usb-audio card it's worse. I have to use the "Speaker"
control because there's no master. It gets wrong at almost each use.
It can take several seconds keeping the up key repeating before reaching
100%. Even if sometimes it works fine for some time, it's almost
impossible to set it correctly with the mixer_applet2, while as usual it's
always working fine with alsamixer. Sadly the usb-audio doesn't appear
to have an OSS emulation API.

I can also notice that if I change the volume on alsamixer, the
(2.20.1-3) mixer_applet2 also randomly shows the false mute.

Other interesting info, but it's no more with mixer_applet2: if I run
gnome-volume-control (which behaves as bad as mixer_applet2) and change
the sound on alsamixer, the bug appears.  gnome-volume-control, by just
being around makes the sound control unstable even if changing its settings
with alsamixer.

Debug should be done with a usb-audio card, much more interesting samples.


regards,
A.B

I'm experiencing this bug, too.

I'm using Debian Lenny. 
The "about" window for the Volume Applet reports that the version number is 2.22.3, and that it is using GStreamer 0.10.
The soundcard I have in my computer is a Creative labs Soundblaster Live!, which uses the "snd_emu10k1" driver.

While I'm at it, when I used to change the volume using the scroll wheel in earlier versions, a tooltip would appear while I did this, telling me what percentage the volume was being changed to. Now, this doesn't happen any more. I'd like to see this feature return. 
Maybe if some people like it but others don't, it could be enabled or disabled by an option in the preferences menu.

Has anybody ever seen this again in 2.30 or 2.32?
Mixer code has seen some changes in the meantime...

Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for.
Thanks!