Bug 9374

Rafael, this is a post-2.6.23 regression.

Thanks.

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).

> 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!

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.

> 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 
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.

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.

Thanks!