GNOME Bugzilla – Bug 478485
Scale gets out of sync with hardware levels
Last modified: 2008-07-27 02:00:06 UTC
Using the attached patch, which logs get/set on the volume, I can see that log: ** Message: set: volume 0• ** Message: get: volume 0.000000 (scale 0.000000) mute 0 1• ** Message: get: volume 0.000000 (scale 0.000000) mute 0 1• ** Message: set: volume 11• ** Message: set: volume 31• ** Message: get: volume 0.000000 (scale 100.000000) mute 0 1• ** Message: get: volume 0.000000 (scale 100.000000) mute 0 1• (31 is the upper level of my master track mixer) This means that the "set 11" and "set 31" failed (GstAlsa has _no_ error checking whatsoever). The patch from bug 370937 might help a tad bit.
Created attachment 95884 [details] [review] test patch
Created attachment 95888 [details] [review] patch This is the patch I'll use in Fedora (minus the debugging obviously). It forces use of the values gathered from the scale, or passed from the notifications with _refresh(). I would be much better to never have GStreamer failing to set the volume, but I guess that's what you get when you deal with hardware. This is a mixture of the patch in comment 1, the one in bug 370937, and what's explained above.
Can you separate this into two patches, one to fix the actual bug and one to use the messages? That makes it easier to see in svn which patch did what.
I'd need to wait for bug 370937's patch to be committed, and I'll update the patch with the details of what it does.
Created attachment 96160 [details] [review] gnome-applets-2.20.0-mixer-out-of-sync.patch Updated patch to avoid crashes when the message isn't a volume message nor a mute message.
*** Bug 479749 has been marked as a duplicate of this bug. ***
Created attachment 97125 [details] [review] gnome-applets-2.20.0-mixer-out-of-sync.patch Updated patch to handle the mute state properly when activated from the menu item (see https://bugzilla.redhat.com/show_bug.cgi?id=320451)
Mandriva has applied the mixer-out-of-sync.patch to gnome-applets in Cooker (upcoming Mandriva 2008.1) but the gstreamer alsamixer notifications do not work as expected. Whenever the volume is changed by another app, for example gnome-settings-deamon/plugin/media-keys or gnome-volume-control, the mixer_applet receives one notification of type GST_MIXER_MESSAGE_VOLUME_CHANGED, but the volumes, regardless of what they are actually set to, are always zero. The gnome_volume_applet_refresh function will set the dock icon to muted. No further notifications are received for subsequent volume changes until the mixer_applet volume is changed directly by scrolling the mouse wheel over the dock icon or popping up the applet volume adjustment and changing the volume. Note that the icon will be set to mute while sound continues to play unless the external apps set the actual volume to zero. No MUTE_TOGGLED notifications are ever received. Looking at the code, it seems reasonable and suggests that the problem is in the gstreamer alsa callback code or somewhere lower in alsa. See Mandriva bug report http://qa.mandriva.com/show_bug.cgi?id=37668 It would be interesting to know if this patch works correctly in other distributions. The current Mandriva Cooker gstreamer alsamixer revision is gstreamer0.10-plugins-base-0.10.17-1mdv2008.1 and libalsa is libalsa2-1.0.16-1mdv2008.1, libalsa-plugins-1.0.16-1mdv2008.1
Re Comment #8, I've located the source of this problem as a bug in gstreamer-plugins-base/ext/alsa/gstalsamixertrack.c and have reported it to gstreamer. See http://bugzilla.gnome.org/show_bug.cgi?id=518082 for details. It applies only to sound cards with dual playback/capture capabilites, specifically to the Audigy2 but possibly others. $ amixer -c 0 info Card hw:0 'Audigy2'/'Audigy 2 [SB0240] (rev.4, serial:0x10071102) at 0xa000, irq 20' Mixer name : 'SigmaTel STAC9721,23' Components : 'AC97a:83847609' Controls : 213 Simple ctrls : 48 $ amixer -c 0 | head Simple mixer control 'Master',0 Capabilities: pvolume pvolume-joined cvolume cswitch cswitch-joined Playback channels: Mono Capture channels: Front Left - Front Right Limits: Playback 0 - 100 Capture 0 - 31 Mono: Playback 9 [9%] [-36.40dB] Front Left: Capture 0 [0%] [-46.50dB] [on] Front Right: Capture 0 [0%] [-46.50dB] [on] Simple mixer control 'Tone',0 Capabilities: pswitch
Not sure if this is related, but when using the mousewheel with the mouse pointer over the volume control panel icon, if you roll past the top or bottom of the range, the volume randomly mutes or becomes extremely loud, and sometimes the channels separate (one channel is louder than the other, or just one is muted).
Bug 478512 is very similar to this one.
(In reply to comment #10) > Not sure if this is related, but when using the mousewheel with the mouse > pointer over the volume control panel icon, if you roll past the top or bottom > of the range, the volume randomly mutes or becomes extremely loud, and > sometimes the channels separate (one channel is louder than the other, or just > one is muted). I can confirm this bug, it starts after upgrading to kernel 2.6.25. This strange behavior happens using mouse wheel, slider on both applet and gnome-volume-control and with multimedia keys too
(In reply to comment #10) > Not sure if this is related, but when using the mousewheel with the mouse > pointer over the volume control panel icon, if you roll past the top or bottom > of the range, the volume randomly mutes or becomes extremely loud, and > sometimes the channels separate (one channel is louder than the other, or just > one is muted). > I am also suffering EXACTLY the same behavior now with kernel-2.6.25 under Gentoo Linux
This may or may not be related, but the LCD backlight brightness applet also seems to have some similar weird problems with brightness levels jumping around a little as you move the scrollwheel with the mouse pointer over it, although it doesn't have the same problems with extreme jumps when the min and max range values are reached.
I've applied Bastien's patch to SVN.