Description of problem: When the Master volume is set to less than 100%, it start slowly drifting (time scale 10-20s) back to 100% and the volume increases. The volume control applet setting remains unchanged. When the volume applet widget is just touched, the volume is reset back to the original value. "PCM" and "Front" settings do not drift. Version-Release number of selected component (if applicable): kernel-2.6.23.1-42.fc8 alsa-lib-1.0.15-1.fc8.x86_64 How reproducible: Always. This must be some recent problem because it did not happen few days ago and I track the updates closely every 1-3 days.
What was the version of the previous kernel that worked?
I see now it must have happen earlier: kernel-2.6.23.1-37.fc8 drifts as well. kernel-2.6.23-0.214.rc8.git2.fc8 does NOT drift. I have to find now some kernels in between.
Please run the soundcard detection utility and go to the third tab and generate a report, then attach it to this bugzilla.
2.6.23.1-35.fc8 is ok, 2.6.23.1-36.fc8 isn't. I note that the latter presents a "Master" Volume control widget while the former does not.
Created attachment 244991 [details] scsconfig.log created with 2.6.23.1-42.fc8
Please take a look at https://bugzilla.redhat.com/show_bug.cgi?id=354981 And also at http://mailman.alsa-project.org/pipermail/alsa-devel/2007-November/003817.html We are discussing a similar bug there.
Looks like an identical bug to me. *** This bug has been marked as a duplicate of 354981 ***
Since your report is a bit different, I want to suggest you to start alsamixer in console using this command: alsamixer -D hw:0 and change master volume here. Does this work?
alsamixer -D hw:0 behaves identically as gnome-volume-control: when the master volume is reduced, the actual volume starts drifting up, but the position of the control widget in alsa-mixer remains unchanged. Pressing <Up> or <Down> key resets the actual volume to the level visualized by alsamixer - and then it starts drifting again... Also as with g-v-c, values set for PCM and Front channels stay fixed, no drift is observed.
Great. It is probably hardware bug. All I do is I set hardware control 'VolumeKnob' probably it is broken on your stac (Probably all STAC9205s have this bug, since windows driver doesn't use it, and linux drivers wasn't using it till I added support for it) I wait and see whenever I get more bug reports. Meanwhile just ignore the 'Master' control. and use 'Front' instead like you did before. Best regards, Maxim Levitsky
Also you can use 'PCM' to lower the volume in software.
Thanks for tracking this down. Now, I need to figure out how to change the binding in gnome-keybinding-properties of "Volume Up" action from controlling the Master Volume to controlling the Front or PCM volumes. (but this is out of the scope for this bug).
I can revert the commit that added the support for that control; we can see if that helps.
It will 100% help, but I don't yet know whenever the VolumeKnob is broken on very few systems, or it is broken on all STAC9205 or maybe even in all STAC9204/54/55 codecs
Pawel Salek, can you give me contents of /proc/asound/Intel/codec* I want to know what STAC codec exactly you have to track down what codecs don't have good VolumeKnob
Created attachment 248861 [details] Contents of /proc/asound/Intel/codec#[01] Contents attached. There are two codecs available. #0 is SigmaTel STAC9205 (audio?), #1 is Conexant ID 2c06 (modem?)
Thank you very much. The Conexant ID 2c06 is modem, and it is unrelated. You have the same STAC9205 as in 354981. Best regards, Maxim Levitsky