Most recent kernel where this bug did not occur: 2.6.23
x86_64 Pentium D system; ICH7 chipset
00:1b.0 Audio device : Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller [8086:27d8] (rev 01)
Software Environment: Debian Unstable, KDE Desktop
If I change the volume using the master control slider in KDE, the sound will first go down to a very low volume (almost muted with slider at 2/3 _up_) and then, in about 10 seconds, come slowly back up to its "normal" volume for the position of the slider. The volume does vary while I move the slider, but even at the very top it is very low at first.
This only happens with the master slider, the PCM and front sliders behave normally.
There were some changes from 2.6.23 to 2.6.24. During first boot of .24 I get:
Setting up ALSA...warning: 'alsactl restore' failed with error message '
alsactl: set_control:989: warning: name mismatch (Capture Volume/Input Source) for control #2
alsactl: set_control:991: warning: index mismatch (0/1) for control #2
alsactl: set_control:993: failed to obtain info for control #2 (Operation not permitted)'
I also suddenly have a lot more controls (some probably bogus):
Output: master, PCM, front, surround, center, LFE, digital, mux, mux
Input: capture, capture, digital, mux, mux
Also, the rear output jack responds to the "front" output slider, as does the front output jack. Not sure if that is a regression or not; will check.
Can provide any additional info needed.
Rafael, this is a post-2.6.23 regression.
Which hardware and codec? Show the PCI SSID (lsusb -nvv) and the contents of /proc/asound/card0/codec#* files.
I guess it's STAC9205, judging from the symptom. There are similar bug reports
Also, which audio I/O does your system have?
The warnings from alsactl are no regressions but it's a failure of the init script that doesn't use a proper option (-F).
> Show the PCI SSID (lsusb -nvv)
Guess you mean lspci? Here is the output of that for the device:
0:1b.0 0403: 8086:27d8 (rev 01)
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 22
Region 0: Memory at 903c0000 (64-bit, non-prefetchable) [size=16K]
Capabilities:  Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=55mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities:  Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable-
Address: 0000000000000000 Data: 0000
Capabilities:  Express Unknown type IRQ 0
Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag-
Device: Latency L0s <64ns, L1 <1us
Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported-
Device: RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop+
Device: MaxPayload 128 bytes, MaxReadReq 128 bytes
Link: Supported Speed unknown, Width x0, ASPM unknown, Port 0
Link: Latency L0s <64ns, L1 <1us
Link: ASPM Disabled CommClk- ExtSynch-
Link: Speed unknown, Width x0
> and the contents of /proc/asound/card0/codec#* files
> Also, which audio I/O does your system have?
Hmm. Not sure what you mean by that. Can you be more specific please?
> The warnings from alsactl are no regressions but it's a failure of the
> init script that doesn't use a proper option (-F).
OK. I'll file a bug report against the debian package for that. Thanks!
Created attachment 13540 [details]
> I guess it's STAC9205, judging from the symptom.
Nope. Looks like it is a STAC9221.
> Also, the rear output jack responds to the "front" output slider, as does
> the front output jack. Not sure if that is a regression or not; will check.
This is not a regression. Apparently "front" controls both output jacks.
Would it make sense to rename "front" to "master" maybe?
> I also suddenly have a lot more controls (some probably bogus):
> Output: master, PCM, front, surround, center, LFE, digital, mux, mux
> Input: capture, capture, digital, mux, mux
The second capture and mux controls are indeed new, as are several others. Will attach old and new output of 'amixer'. Should they really be there?
The diff is:
+Simple mixer control 'Master',0
+Simple mixer control 'Capture',1
+Simple mixer control 'Input Source',1
+Simple mixer control 'Mux',1
+Simple mixer control 'Swap Center/LFE',0
Created attachment 13542 [details]
amixer output for .23 and .24 kernels showing new (bogus?) controls
My question was what physical I/O (front line-out jack, speaker-out, shared line-in jack, etc) does your system have. According to the PCI SSID, it looks like a D945G 3-stack model. Correct?
The "Front" is indeed front but it manages the front *channel* volume. When you play 2-channel samples, then this volume will influence on all outputs, because the same signal is routed to all outputs. If you play 5.1 output, the other channels are controlled via different mixer elements.
The other new mixer controls are OK and should work. The driver supports the secondary capture control and has a mixer switch to swap center/lfe assignment.
The only question is "Master" control.
So, on your system, changing "Master" volume doesn't work properly? Is it the same symptom found in the redhat bugzilla above?
On Wednesday 14 November 2007, you wrote:
> My question was what physical I/O (front line-out jack, speaker-out,
> shared line-in jack, etc) does your system have. According to the PCI
> SSID, it looks like a D945G 3-stack model. Correct?
Ah, OK. Yes, it is an Intel Desktop Board D945GCZ. My system has:
- back panel connectors: line in, line out, mic
- front panel connectors: line out, mic
I'm not actually sure if I have the "tripple stack" connector or not. It's
listed as optional and the manual does not really say how I can tell if
it's there or not. If it is, the back panel connectors should double as
rear out, front out and center/LFE.
The manual lists also two optional _separate_ back panel connectors
("Center/LFE out" and "Rear left and right out") but those are *not*
present on my system. Maybe that indicates that I _do_ have the tripple
stack. It would also explain the switches I see in the volume control apps.
Thanks for the explanations.
> The only question is "Master" control.
> So, on your system, changing "Master" volume doesn't work properly? Is
> it the same symptom found in the redhat bugzilla above?
Yes, the descriptions of the problem seem to match.
It's a so-called "3stack", that has 3 jacks in rear. Usually line-in/mic-in are shared with surround outputs in this case. There are models that have 5 or 6 jacks for separate in and out jacks.
According to Maxim, who added the new Master volume feature, the problem depends rather on hardware. So, we might need to blacklist/whitelist devices...
To be sure, could you check the patch below? This should fix a warning (switching to polling mode) you might have seen in your kernel message log.
Created attachment 13544 [details]
Fix invalid PINCAP access
> To be sure, could you check the patch below?
The patch does not change the behavior of the master control: the volume
still gradually increases back to 100% after the slider is moved down.
I don't see any problems with the patch either.
> This should fix a warning (switching to polling mode) you might have seen
> in your kernel message log.
I have never seen that message (I have logcheck running on my desktop, so
it's unlikely I would have missed it, and a grep does not show it in my
> According to Maxim, who added the new Master volume feature, the problem
> depends rather on hardware. So, we might need to blacklist/whitelist
The question is of course whether the hardware is broken or whether there is
some missing understanding of its specs :-P
I would personally be happy enough without a master control slider though.
Thank you for your quick responses so far.
The patch reverting the volume knob part is now in ALSA tree. It'll be (hopefully) merged timely to 2.6.24-rc4...
does this mean what i think it means? this will break my multimedia (volume up and down) keys again?
Fix is included in mainline now.
Please provide the commit ID and subject.