Bug 9374

Summary: [ICH7 snd_hda_intel] Volume control broken
Product: Drivers Reporter: Frans Pop (elendil)
Component: Sound(ALSA)Assignee: Jaroslav Kysela (perex)
Status: CLOSED CODE_FIX    
Severity: normal CC: rjw, tiwai
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: v2.6.24-rc2-409-g9418d5d Subsystem:
Regression: Yes Bisected commit-id:
Bug Depends on:    
Bug Blocks: 9243    
Attachments: /proc/asound/card0/codec#2
amixer output for .23 and .24 kernels showing new (bogus?) controls
Fix invalid PINCAP access

Description Frans Pop 2007-11-13 16:56:06 UTC
Most recent kernel where this bug did not occur: 2.6.23
Distribution: Debian

Hardware Environment:
x86_64 Pentium D system; ICH7 chipset
00:1b.0 Audio device [0403]: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller [8086:27d8] (rev 01)

Software Environment: Debian Unstable, KDE Desktop

Problem Description:
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.
Comment 1 Andrew Morton 2007-11-13 18:11:39 UTC
Rafael, this is a post-2.6.23 regression.

Thanks.
Comment 2 Takashi Iwai 2007-11-14 03:04:56 UTC
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
    https://bugzilla.redhat.com/show_bug.cgi?id=361051

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).
Comment 3 Frans Pop 2007-11-14 03:32:31 UTC
> 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)
        Subsystem: 8086:0101
        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: [50] 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: [60] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable-
                Address: 0000000000000000  Data: 0000
        Capabilities: [70] 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
Will attach.

> 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!
Comment 4 Frans Pop 2007-11-14 03:34:56 UTC
Created attachment 13540 [details]
/proc/asound/card0/codec#2

> I guess it's STAC9205, judging from the symptom.

Nope. Looks like it is a STAC9221.
Comment 5 Frans Pop 2007-11-14 04:56:11 UTC
> 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
Comment 6 Frans Pop 2007-11-14 04:57:36 UTC
Created attachment 13542 [details]
amixer output for .23 and .24 kernels showing new (bogus?) controls
Comment 7 Takashi Iwai 2007-11-14 05:13:41 UTC
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?
Comment 8 Frans Pop 2007-11-14 06:05:54 UTC
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.
Comment 9 Takashi Iwai 2007-11-14 08:34:46 UTC
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.
Comment 10 Takashi Iwai 2007-11-14 08:36:22 UTC
Created attachment 13544 [details]
Fix invalid PINCAP access
Comment 11 Frans Pop 2007-11-15 00:05:17 UTC
> 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 
logs either).

> According to Maxim, who added the new Master volume feature, the problem
> depends rather on hardware.  So, we might need to blacklist/whitelist
> devices...

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.
Comment 12 Takashi Iwai 2007-11-20 03:55:07 UTC
The patch reverting the volume knob part is now in ALSA tree.  It'll be (hopefully) merged timely to 2.6.24-rc4...
Comment 13 Thomas Meyer 2007-11-20 13:03:04 UTC
does this mean what i think it means? this will break my multimedia (volume up and down) keys again?
Comment 14 Frans Pop 2007-11-30 12:05:42 UTC
Fix is included in mainline now.
Comment 15 Rafael J. Wysocki 2007-12-01 13:24:47 UTC
Please provide the commit ID and subject.

Thanks!