GNOME Bugzilla – Bug 478512
[alsamixer] volume control slider not working
Last modified: 2009-10-20 17:18:58 UTC
Please describe the problem: the gnome-volume-control program allows the slider to be modified and both left and right move at the same time but once i let go of the slider the left channel bounces to 0% and the right channel stays where it is. Also, the mute setting seems to randomly go on and off when changing the slider. Possibly due to the left channel going to 0%. Steps to reproduce: 1. Open up the gnome-volume-control program 2. Move the PCM slider around. 3. As soon as you let go the left channel goes to 0% and the right channel stays at the same volume Actual results: As soon as you let go the left channel goes to 0% and the right channel stays at the same volume Expected results: It should just increase or decrease the volume Does this happen every time? Yes Other information: It seems to be a problem with the gnome-volume-control program, the gnome-volume applet, and the keyboard volume control In each program the problem varies slightly...ie. the gnome-volume applet can go from 0%->100% but it only changes the right channel leaving the left at 0%. The keyboard control only allows up to 13%ish and only adjusts the right channel System Specs: Gnome is running on a archlinux compiled under x86_64. Also using the Plantronics Headset. Which uses the snd_usb_audio kernel driver. Linux <hostname> 2.6.22-suspend2 #1 SMP PREEMPT Sat Sep 1 13:56:25 CEST 2007 x86_64 AMD Opteron(tm) Processor 242 AuthenticAMD GNU/Linux
*** Bug 478505 has been marked as a duplicate of this bug. ***
*** Bug 478504 has been marked as a duplicate of this bug. ***
It seems to occur in version 2.20.x as well.
Given your description, this seems like a gstreamer plugin problem, the apps seem to do what I would expect given a common problem in the plugin from gst. Please file a bug upstream there (feel free to CC me).
Possibly my problem is related to the reporter's one. When changing the volume with the volume applet slider (or with the mouse wheel), the volume symbol "flickers" from the expected "accoustic waves" icon to the "muted" icon back and forth. This seems to be one of the symptoms Isaac is observing. However, the sound does not really mute, it's just the icon that behaves strange. When I adjust the volume with the terminal alsa mixer, this bug does not occur. Also, when I switch from ALSA mixer to OSS mixer, the gnome volume applet behaves correctly again.
-> gst
"When changing the volume with the volume applet slider (or with the mouse wheel), the volume symbol "flickers" from the expected "accoustic waves" icon to the "muted" icon back and forth. This seems to be one of the symptoms Isaac is observing. However, the sound does not really mute, it's just the icon that behaves strange." -> I have this exact same problem with my fresh Ubuntu 7.10 installation. I noticed it very quickly since I am used to just scroll over the volume control applet to change the volume. This problem did not occur on my previous Ubuntu 7.04 installation.
As this has changed from gnome-media to a gstreamer problem, here are the relevant gstreamer version numbers local/gstreamer0.10 0.10.14-1 GStreamer Multimedia Framework local/gstreamer0.10-alsa 0.10.14-1 (gstreamer0.10-plugins) GStreamer alsa plugin local/gstreamer0.10-bad 0.10.5-2 (gstreamer0.10-plugins) GStreamer Multimedia Framework Bad Plugins (gst-plugins-bad) local/gstreamer0.10-base 0.10.14-1 (gstreamer0.10-plugins) GStreamer Multimedia Framework Base Plugins (gst-plugins-base) local/gstreamer0.10-cdparanoia 0.10.14-1 (gstreamer0.10-plugins) GStreamer CDParanoia plugin local/gstreamer0.10-flac 0.10.6-1 (gstreamer0.10-plugins) GStreamer flac plugin local/gstreamer0.10-gconf 0.10.6-1 (gstreamer0.10-plugins) GStreamer GConf plugin local/gstreamer0.10-good 0.10.6-1 (gstreamer0.10-plugins) GStreamer Multimedia Framework Good Plugins (gst-plugins-good) local/gstreamer0.10-musicbrainz 0.10.5-1 (gstreamer0.10-plugins) GStreamer musicbrainz plugin local/gstreamer0.10-ogg 0.10.14-1 (gstreamer0.10-plugins) GStreamer OGG plugin local/gstreamer0.10-vorbis 0.10.14-1 (gstreamer0.10-plugins) GStreamer Vorbis plugin Also, I have upgraded to gnome 2.20 and the problem still occurs. The gnome-volume-control program seems to behave better than before, however the keyboard volume control still mucks the sliders up and moving the sliders around back and forth fast seem to make the problem occur. As for Adalbert's problem, I appear to have the same problem. I would also like to add that when using gnome-alsamixer its volume control works fine. I suspect it uses a different way of changing the volume so I hope this helps in narrowing where the problem could be.
Additional information can be found here. https://bugs.launchpad.net/ubuntu/+source/gstreamer/+bug/158590 I'm getting this too, so I can provide a bit more information. This is a problem that seems to be exclusively with USB audio output. The issue is with the gstreamer ALSA mixer plugin - it seems that gstreamer somehow does not set the ALSA mixer variables in the proper way (i.e. how alsamixer and gnome-alsamixer do it). If any gstreamer-based mixer app is open and has access to the mixer component, then the command-line alsamixer will exhibit the same erratic behavior. Only after closing all gstreamer-based mixer apps will alsamixer work.
Ubuntu Bug# 158590 seems to describe the problem accurately. I also found https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/155109 Which describes the problems as well, this one seems more accurate to what I'm seeing. As it appears to be a problem with USB audio, I'm using a Plantronics 750 DSP headset. Since there seems to be quite a number of people with this bug, is it possible to confirm this bug?
Is this the same issue as bug #486840? Could anyone try with core+gst-plugins-base from CVS to see if the issue persists?
I've just checked out gstreamer and gst-plugins-base from CVS and the problem still remains the same (*) I had the exact same problem I'm having now (i.e. left channel jumping to zero, right channel beeing raised/lowered as requested). By the way, I'd like to add that at the Launchpad.net Bug, every one reporting to have the same problem seems to be using a USB sound device. (*) I'm not entirely sure if my way of testing was ok, so I'll report it here: I basically did a ./configure --prefix=$HOME/tmp/gst && make && make install for both gstreamer & gst-plugins-base (with PACKAGE_CONFIG_PATH set for the later) and then ran "LD_LIBRARY_PATH=$HOME/tmp/gst/lib/ gnome-volume-control". I've checked /proc/$(pidof gnome-volume-control)/maps and it seems to correctly load the just-compiled gst libraries from $HOME/tmp/gst/lib
Got the same problem, volume control through GStreamer framework is just behaving crazy (using the Gnome volume control app, for instance). Alsamixer (console) works fine. I've got an external Creative Xmod hooked up via USB.
Sorry, I forgot to mention: I'm using Ubuntu Gutsy with standard packages.
I'm seeing this too with Logitech V20 USB speakers.
Bug 478485 and bug 478498 are very similar to this one.
I get erratic volume slider behaviour here myself, but only when Firefox is running and its worse when Firefox is the active window. The stereo sliders split apart on their own, and the sliders move in opposite directions....epiphany and seamonkey: same thing happens. Gecko 1.8x. Seems strange that a web browser might interfere with the multimedia keys in gnome, but that's how I see it here: So heres how I see it: firefox (and thunderbird) running) I use the vol down key and its fine for a moment or two...use it a few minutes later and the level is erratic. Mute works. No running gecko engine, no audio keys problems here. Try it yourself!
I see exactly the same bug here on acer aspire 5720. It has a ordinary ALC268 HDA codec. The volume jumps/mutes on a single channel, when do following: 1) rotate the volume knob To test that volume knob isn't guilty I assigned the volume up/down to ctrl+ up/down, and I see exactly the same behavior. 3) When I change the volume using the "mouse wheel" , I mean I move finger on the touchpad, over the volume icon, same happens. 4) If I change the volume using drop-down menu of the volume applet same happens.
I'm now running gnome 2.22 with kernel version 2.6.25 and it still has the same problem As mentioned before, I've tested it with USB speakers and with and an internal sound card and the problem is only with USB speakers. So it would seem that the api to change the alsa volumes is faulty when communicating to a USB device.
Here the problem happens only with 2.6.25 kernel (both vanilla and tuxonice patched), I switched back to 2.6.24 and all works well. It should be related with the alsa driver version in the new kernel, shouldn't it?
I was running 2.6.24 before and the problem was still there.
This is pretty bad for affected users. Increasing priority and severity.
I have this with my usb headset too. Teppo, that severity and priority does not help, we try to fix all problems.
I found a way to work around this (that is, to actually change the volume on my USB speakers): 1. Set PCM volume to zero (don't mute, drag the slider to the bottom). 2. Separate/Unlock the PCM channels. 3. Adjust left channel to desired volume. 4. Adjust right channel to the same volume. It doesn't work the other way around (right channel first) and you always have to go through zero to change the it.
Theres a better way than that. If you download/compile and install gnome-alsamixer. It can change volumes without the left/right channel going nuts.
I am also affected by this, even with gst-plugins-base-0.10.20 and gstreamer 0.10.20 , this could be maybe related with http://bugzilla.gnome.org/show_bug.cgi?id=478498
My instalation is showing simmilar symptoms. I am not using any usb sound device. I have laptop with integrated Intel HDA. I am using x86_64 with following software versions: GNOME 2.22.3 gstreamer0.10-base 0.10.20 alsa-lib 1.0.16 kernel 2.6.26.2
I've just upgraded to kernel 2.6.27 and the problem disappeared, I'm using in-kernel alsa driver.
Can those of you affected by this bug try the patch in bug #545932, which may very well be the same issue?
I had been suffering from this bug for over a year, with Debian unstable on a Dell Precision M20 laptop (same hardware as Latitude D610, Intel ICH6 with STAC9750,51). It showed up when a video was playing or a Flash applet was present in a browser. Upgrading from 2.6.25 to 2.6.27 made no difference. The suggestion from xt.knight at https://bugs.launchpad.net/ubuntu/+bug/252237, posted here in bug #545932, was to revert this commit: http://webcvs.freedesktop.org/gstreamer/gst-plugins-base/ext/alsa/gstalsamixer.c?r1=1.37&r2=1.38 Doing this fixed the problem for me. Please, either revert this change upstream or fix whatever problem it has introduced in some other way. It makes volume control utterly unusable for the whole system.
FYI. the commit mentioned in comment #30, was done in order to implement the feature requested in bug #152864.
This is due to race conditions between functions that modified the mixer like set_volume and snd_mixer_handle_events since the handle_events can now be called at any time. Fixed by adding locking around any snd_mixer call since even read functions can modify the mixer stucture. (Since alsa likes to clear it's values before reading new ones) The favorite race condition seemed to be that set_volume called read_elem (in alsalib) that reset the volumes to 0 and then read them with read_x_volume. This read looped on each channel and as the race condition occured the channels value could be anything , most of the time it was 0.. Thus no value was read or only the value of one channel was and the volume was reset to 0. Note that I also cleaned up the poll code...
Created attachment 127874 [details] [review] git patch
Created attachment 127875 [details] [review] Patch for gstreamer 0.10.20
There is an error in those 2 patches.. There is nothing to stop the poll.. set_state_null when the thread_join is execed... so it deadlocks fixing please wait before review/apply
Created attachment 127879 [details] [review] poll code was ok my bad...
Just to give a little feedback: The latest patch (id 127879) works fine for me. No deadlocks, no volume drops to zero and no randomly enabled recording when changing the volume of capture tracks anymore.
Created attachment 127882 [details] [review] git patch left pool code as it was... sorry
(In reply to comment #38) > Created an attachment (id=127882) [edit] > git patch I tested this against gstreamer-plugins-base 0.10.19-2 from Debian lenny and it fixes the problem for me. Thanks for the patch!
commit fc23037a9aaf0beca99f9494948b2fb1169a03db Author: Antoine Tremblay <hexa00@gmail.com> Date: Tue Feb 10 11:00:12 2009 +0100 alsamixer: Fix race condition that made alsamixer not working properly This is due to race conditions between functions that modified the mixer like set_volume and snd_mixer_handle_events since the handle_events can now be called at any time. Fixed by adding locking around any snd_mixer call since even read functions can modify the mixer stucture, since alsa likes to clear it's values before reading new ones. The favorite race condition seemed to be that set_volume called read_elem (in alsalib) that reset the volumes to 0 and then read them with read_x_volume. This read looped on each channel and as the race condition occured the channels value could be anything , most of the time it was 0. Thus no value was read or only the value of one channel was and the volume was reset to 0. Fixes bug #478512.
Awesome! thanks for your effort!
*** Bug 570378 has been marked as a duplicate of this bug. ***
*** Bug 545932 has been marked as a duplicate of this bug. ***