Bug 42588 - ALC660(861) HD Audio on ATI IXP SB4x0 stopped working from 3.2.0-rc1 to 3.2.1
ALC660(861) HD Audio on ATI IXP SB4x0 stopped working from 3.2.0-rc1 to 3.2.1
Status: RESOLVED CODE_FIX
Product: Drivers
Classification: Unclassified
Component: Sound(ALSA)
All Linux
: P1 normal
Assigned To: Jaroslav Kysela
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-01-16 09:08 UTC by Tom D.
Modified: 2012-02-11 15:25 UTC (History)
4 users (show)

See Also:
Kernel Version: 3.2.1 3.2.0-rc7 3.2.0-rc1
Tree: Mainline
Regression: Yes


Attachments
alsa-info no-sound 3.2.0-rc1 (16.39 KB, text/plain)
2012-01-16 09:08 UTC, Tom D.
Details
alsa-info working 3.1.9 (24.22 KB, text/plain)
2012-01-16 09:09 UTC, Tom D.
Details
/proc/asound/devices info (278 bytes, text/plain)
2012-01-16 09:10 UTC, Tom D.
Details
/proc/asound/cards info (99 bytes, text/plain)
2012-01-16 09:10 UTC, Tom D.
Details
/proc/asound/pcm info (122 bytes, text/plain)
2012-01-16 09:11 UTC, Tom D.
Details
Audio device lspci (938 bytes, text/plain)
2012-01-16 13:56 UTC, Tom D.
Details
Alsa-info on 3.1.9 vanilla (24.10 KB, text/plain)
2012-01-18 15:20 UTC, Tom D.
Details
Alsa-info on 3.2.1 vanilla NOT working sound (16.86 KB, text/plain)
2012-01-18 15:22 UTC, Tom D.
Details
Alsa-info on 3.2.1 set Auto-Mute Mode=Enabled (16.84 KB, text/plain)
2012-01-19 11:48 UTC, Tom D.
Details
Alsa-info on 3.2.1 set AMM and try playing sound (19.39 KB, text/plain)
2012-01-19 11:50 UTC, Tom D.
Details
Pins check (723 bytes, text/plain)
2012-01-19 14:23 UTC, Tom D.
Details
A patch to fix 0x0f pin-setup for ASUS A6Rp (930 bytes, patch)
2012-01-23 11:19 UTC, Takashi Iwai
Details | Diff
Patch to apply the VREF-fix for ASUS laptops (1.62 KB, patch)
2012-01-30 09:51 UTC, Takashi Iwai
Details | Diff
rejected code from the patch (751 bytes, text/plain)
2012-01-30 10:27 UTC, flyingnu
Details
Revised patch to apply the VREF-fix for ASUS laptops (2.53 KB, patch)
2012-01-30 10:45 UTC, Takashi Iwai
Details | Diff
Patch to apply the VREF-fix for ASUS laptops (v3) (3.41 KB, patch)
2012-01-30 13:21 UTC, Takashi Iwai
Details | Diff
Patch to apply the VREF-fix for ASUS laptops (v4) (3.96 KB, patch)
2012-01-30 15:29 UTC, Takashi Iwai
Details | Diff

Description Tom D. 2012-01-16 09:08:02 UTC
Created attachment 72083 [details]
alsa-info no-sound 3.2.0-rc1

Overview:
After updating from vanilla 3.1.9 to 3.2.1 audio stopped working. After short seeking problem starts at 3.2.0-rc1.

Steps to Reproduce:
1. Compile ALSA as build-in
2. run aplay /usr/share/sounds/alsa/Front_Center.wav

Actual Results:
No sound

Expected Results:
Play sound

Build Date & Platform:
14 Jan 2012 on up-to-date Funtoo Linux ~x86

Additional Information:
1. Driver is build-in
2. /etc/modprobe.d/alsa.conf; /etc/asound.conf; ~/.asoundrc moved to .backup or unmodified
3. cat /proc/cmdline -> BOOT_IMAGE=/linux-3.2.0-rc1 root=/dev/sda6
4. ALSA-utils-1.0.24.2; ALSA-lib-1.0.24.1; ALSA driver 1.0.24
5. BIOS checked HD audio unlocked
6. Alsamixer, F6 select card; F5 checked levels all ~50%
7. Checked speakers and headphones; in headphones some noise only when run aplay
8. attached /proc/asound/{pcm,devices,cards}, alsa-info{3.1.9,3.2.0-rc1}
Comment 1 Tom D. 2012-01-16 09:09:26 UTC
Created attachment 72084 [details]
alsa-info working 3.1.9
Comment 2 Tom D. 2012-01-16 09:10:10 UTC
Created attachment 72085 [details]
/proc/asound/devices info
Comment 3 Tom D. 2012-01-16 09:10:42 UTC
Created attachment 72086 [details]
/proc/asound/cards info
Comment 4 Tom D. 2012-01-16 09:11:22 UTC
Created attachment 72087 [details]
/proc/asound/pcm info
Comment 5 Tom D. 2012-01-16 13:56:15 UTC
Created attachment 72089 [details]
Audio device lspci
Comment 6 Takashi Iwai 2012-01-18 14:39:54 UTC
Could you run alsa-info.sh (with --no-upload option) on both working (3.1.x) and non-working (3.2.x) kernels, and attach the outputs?
Comment 7 Tom D. 2012-01-18 15:20:41 UTC
Created attachment 72111 [details]
Alsa-info on 3.1.9 vanilla

On this kernel version sound is working only when I check kernel option: Build static quirks for Realtek codecs
Else its like the 3.2.1
Comment 8 Tom D. 2012-01-18 15:22:33 UTC
Created attachment 72112 [details]
Alsa-info on 3.2.1 vanilla NOT working sound

Emerge on EXACT same config. No sound
Comment 9 Takashi Iwai 2012-01-19 11:31:06 UTC
Try to enable "Auto-Mute Mode" mixer control:
   % amixer -c0 set "Auto-Mute Mode" Enabled

Also please give alsa-info.sh output while you are testing the sound output.
Comment 10 Tom D. 2012-01-19 11:48:21 UTC
Created attachment 72123 [details]
Alsa-info on 3.2.1 set Auto-Mute Mode=Enabled

Changing the setting. Not played sound yet.
Comment 11 Tom D. 2012-01-19 11:50:21 UTC
Created attachment 72124 [details]
Alsa-info on 3.2.1 set AMM and try playing sound

Trying to play sound from aplay and others progs. No sound
Comment 12 Takashi Iwai 2012-01-19 12:07:05 UTC
"No sound" means no sound from both speaker and headphone?  Or any output work?

It's likely a broken BIOS on your machine, which doesn't give the proper pin-default configuration.
Comment 13 Takashi Iwai 2012-01-19 12:08:09 UTC
To be clear: which I/O does your machine have?  A headphone jack, a mic jack, a line-in jack, a built-in speaker.  What else?
Comment 14 Tom D. 2012-01-19 12:16:23 UTC
This setting nothing changed. When trying to play from speakers - no sound. When doing that from headphone - noise.

I/O: headphones, mic, line-in, built-in speakers, pcimcia, card reader, modem, ethernet, 4xusb, lpt, analog vga.
Comment 15 Tom D. 2012-01-19 12:17:24 UTC
oh, and cdrom
Comment 17 Tom D. 2012-01-19 12:36:26 UTC
Good settings is model=asus
It`s for Asus A6rp notebook
Comment 18 Takashi Iwai 2012-01-19 13:20:03 UTC
OK, then we need to check first which pin corresponds to what.  Let's begin with the headphone jack.

- Get hda-verb program from ftp://ftp.suse.com/pub/people/tiwai/misc/

- Build your kernel with CONFIG_SND_HDA_HWDEP=y, CONFIG_SND_HDA_RECONFIG=y, and CONFIG_SND_HDA_PATCH_LOADER=y.

- Plug your headphone jack, and run like:
    hda-verb /dev/snd/hwC0D0 0x0e GET_PIN_SENSE 0

  If 0x0e is the right pin, you'll get the value like 0x80000000, i.e. bit 31 is set.  Unplug the jack, and check that the bit 31 is cleared.
  If this can't be seen, retest with 0x0f instead of 0x0e.  Test from 0x0b to 0x12.

- You can check the mic-in and the line-in jacks similarly as well, which are supposed to be 0x0c and 0x0d.
Comment 19 Tom D. 2012-01-19 14:23:31 UTC
Created attachment 72126 [details]
Pins check

It`s wired but there`s nothing. All values 0x7fffffff
Comment 20 Takashi Iwai 2012-01-19 19:38:16 UTC
It might need to trigger the pin-sensing.
Call hda-verb /dev/snd/hwC0D0 $NID SET_PIN_SENSE 0
where $NID is the widget id to test (e.g. 0x0e).
Comment 21 Tom D. 2012-01-20 09:54:29 UTC
When I trigger pin-sensing all values are the same - 0x1ffff. I checked all 3 jacks non of them trigger the sensing.
But when I Call one more time hda-verb $NID SET_PIN_SENSE 0 I get this values:
For:
0x0b - 0x222e
0x0c - 0x1ffff
0x0d - 0xf30
0x0e - 0x13
0x0f - 0x1ffff
0x10 - 0x88b8
0x11 - 0x48e

Values are the same when I plugged and unplugged headphones.
How I do this? I SET $NID and I GET $NID from 0x0b to 0x11.
Comment 22 Takashi Iwai 2012-01-20 10:08:10 UTC
Well, it implies that the jack-sensing on your machine doesn't work.  It's a really bad news.  I wonder whether it's a hardware failure or the intended design.

If the jack-detection doesn't work, you'd need to check in another way.
Grab hda_analyzer, mentioned in Documentation/sound/alsa/HD-Audio.txt in kernel tree.  And play with it.

Or, at least, you can try like below with hda-verb:
   hda-verb /dev/snd/hwC0D0 0x0f SET_PIN_WID 0x40
   hda-verb /dev/snd/hwC0D0 0x1a SET_AMP 0x7200
   hda-verb /dev/snd/hwC0D0 0x1a SET_AMP 0x7300

This will enable the pin 0x0f, route to DAC 0x03 and mixer 0x15.  This might work for the headphone.
Comment 23 Tom D. 2012-01-20 12:48:47 UTC
Ok, after debuging graph from 3.2.1 and 3.1.9, this it what i got:

PIN 0x0b - out       OK
PIN 0x0c - in        OK
PIN 0x0d - in 50VREF FAIL -> in 80 VREF 
PIN 0x0e - out       OK
PIN 0x0f - out HIZ   FAIL -> in 80 VREF
PIN 0x10 - in HIZ    FAIL -> in 80 VREF
PIN 0x11 - none      OK
PIN 0x12 - out       OK
PIN 0x1f - out       OK
PIN 0x20 - out       OK

When set PINs in good position there`s SOUND in headphones and speakers :) Loud and clear. I cant minimalize power.

Don`t check line-in. I can`t switch mic to work. Any help?
Comment 24 Takashi Iwai 2012-01-20 15:25:51 UTC
Interesting.  I guess either pin 0x0f or 0x10 are used for EAPD control.  Could you check to revert others and verify one-by-one?

The reason 0x0d taking VREF50 is that this pin declares that only HIZ and VREF50 are capable.  If it must be VREF80, it's a hardware bug.  We'd need to override the pin capability bits in the software.

About the input: you could change the input-source via selecting the mixer control "Input Source" on 3.1 kernel, right?  To be sure, check "Capture Volume" and "Capture Switch" mixer controls, too.
Comment 25 Tom D. 2012-01-20 19:05:46 UTC
Thanks for cold water. I reboot system and checked all pins. You where right not all 3 pins need change, only one. The 0x0f to VREF50. 2nd capable option.

Volume control is working, after reboot, switched pins and exit hda-analyzer.

Basically this is what I need. I don`t know how to do it permanent in kernel. And there`s mic that is not working, but at least I have sound.
Comment 26 Takashi Iwai 2012-01-21 10:06:16 UTC
OK, it's a good news that 0x0f enables the output.  This must be an EAPD control or similar.

We can add simply a special init verb for this device in the driver.  It can be done even by "patch"-loading, as described in HD-Audio.txt, too.  I'll provide a kernel patch once after all things get clarified.

Regarding the output, still a few tests would be helpful: try to set the pin-control of each output pin to 0, and check whether it influences on either the headphone or the speaker output.  It should be 0x0e and 0x0b, respectively, but to make sure.  If these are really correct pins, check the "Headphone" and "Speaker" mixer mute switches work correctly, too.

Also, does the auto-mute of the speaker work as is?  In some cases, it's implemented in the hardware, thus we need only one output pin in practice.  It's the reason of the test above.

(BTW, this hardware has no playback volume control.  Thus the output volume is controlled in software, either in alsa-lib plugin or PulseAudio.)

The mic-input: did you choose "Input Source" mixer correctly to "Mic"?
Anyway, alsa-info.sh output while you are testing the input would be good for further analysis.
Comment 27 Takashi Iwai 2012-01-23 11:19:43 UTC
Created attachment 72153 [details]
A patch to fix 0x0f pin-setup for ASUS A6Rp
Comment 28 Tom D. 2012-01-24 08:39:06 UTC
Tests I do, and results:
1. Switch sound - 0x0f on 50VREF
2. Switch 0x0b out to none - no sound in speakers, headphones OK
3. Switch 0x0e out to none - speakers OK, no sound in headphones
4. Switch rest of out PINs to none - nothing change.

Switching from speakers to headphones always working good. It`s switching automatically. Settings in mixer are working good ie. master, headphone, speaker is switching on/off.

PCM volume control is working OK. Pcm hasn`t had mute switch from beginning. From HDA Analyzer I found mute switch: It`s Node[0x03] AUD_OUT.
Things to mute PCM:
1. Output Amplifier(Global): Val[0] and Val[1] - check to mute left and right.

Mic switch is Node[0x15] AUD_MIX.
Things to switch mic on:
1. Input Amplifier: Val[2] - unmute and raise it`s value
2. Output Amplifier: Val[0] - unmute and raise it`s value

Can You make mute pcm and mic controls working from mixer ?
Next thing I check is patch.
Comment 29 Takashi Iwai 2012-01-24 09:50:30 UTC
OK, so 0x0b and 0x0e are the real pins to be connected to the outputs while 0x0f is the master mute (or amp) control.  And the HP auto-mute seems working in the hardware by itself without help of software.  This is an unusual case.

Note that "PCM" volume control is implemented in software in alsa-lib softvol plugin.  It works when apps are using this plugin (with the "default" PCM setup).
You have "Master" mute switch, and "Headphone" and "Speaker" mute switches.  These should work for the purpose.  There is no reason to add more mute switch.

About the mic-input: make sure that you choose correctly "Mic" in "Input Source" mixer enum.  If the mic worked with 3.1.x kernel, please give that alsa-info.sh output and the output of non-working case, too, so that we can compare directly between them.
Comment 30 Tom D. 2012-01-24 19:58:11 UTC
About PCM. I only want to include mute into pcm. I agree that there`s too much mute switches. For me better be one PCM WITH mute and that`s it :) But I can live with it as is.

About Mic. I send attachment with this data. It`s Alsa-info 3.1.9 vanilla. Search for Mic in there. There`s also 3.2.1 that is not working.

For input source I switched it and raised from the beginning. It`s not working. In #28 there`s info how to switch it on.

Patch is working correctly.
Comment 31 Takashi Iwai 2012-01-25 08:49:42 UTC
Hm, in alsa-info of 3.1.9 in comment 7, "Input Source" mixer is set to "Line".  So, the mic-in can't be recorded.  This is the only control for the recording source.  It's independent from the analog-input loopback.

If you are talking about the analog-input loopback, then I haven't checked it yet.
Comment 32 flyingnu 2012-01-29 22:38:12 UTC
Hi,

i have the same issue here on an Asus f3ja-ap061h with an ALC660 sound card. I previously reported that on the debian bug tracking system http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=657302#45 here you can find alsa-info.sh logs.

However with the help of hda-analyzer i found that switching 0x0f VREF's value to something other than HIZ (50, 80, 100 or GRD) fix the issue and then audio start working both from headphone's jack and from laptop's speakers.
But I had to change it again from hda-analyzer each time i plug or un-plug the headphone but probably this is the expected behaviour by just using hda-analyzer.
Comment 33 Takashi Iwai 2012-01-30 09:50:55 UTC
Could you check the patch below?  This enables the VREF fix for all ASUS laptops with ALC861/660.
Comment 34 Takashi Iwai 2012-01-30 09:51:55 UTC
Created attachment 72227 [details]
Patch to apply the VREF-fix for ASUS laptops
Comment 35 Jaroslav Kysela 2012-01-30 10:06:51 UTC
(In reply to comment #34)
> Created an attachment (id=72227) [details]
> Patch to apply the VREF-fix for ASUS laptops

There is probably a typo:

+	[PINFIX_ASUS_ASUS_A6RP] = {
               ^^^^^^^^^^^
Comment 36 flyingnu 2012-01-30 10:25:56 UTC
also:
-       SND_PCI_QUIRK(0x1043, 0x1393, "ASUS A6Rp", PINFIX_ASUS_A6RP), 
+       SND_PCI_QUIRK_VENDOR(0x1043, "ASUS laptop", PINFIX_ASUS_A6RP),

in the first one we have 4 arguments and in the second one only 3.

On debian kernel:
File to patch: sound/pci/hda/patch_realtek.c
patching file sound/pci/hda/patch_realtek.c
Hunk #1 succeeded at 5225 with fuzz 1 (offset -363 lines).
Hunk #2 FAILED at 5614.
1 out of 2 hunks FAILED -- saving rejects to file sound/pci/hda/patch_realtek.c.rej
Comment 37 flyingnu 2012-01-30 10:27:44 UTC
Created attachment 72232 [details]
rejected code from the patch
Comment 38 flyingnu 2012-01-30 10:30:29 UTC
ehm my fault I didn't see the _VENDOR
Comment 39 Takashi Iwai 2012-01-30 10:44:40 UTC
Yep, that was a typo.  I upload the fixed one below.

But other chunks should be applied to the latest stable-queue for 3.2.  The recent fixes for patch_realtek.c don't appear in the 3.2.x release tree yet but already found in stable-queue tree.  These are the parts conflicting in your case.

The change is trivial, so apply manually by editing the patch.
Comment 40 Takashi Iwai 2012-01-30 10:45:49 UTC
Created attachment 72233 [details]
Revised patch to apply the VREF-fix for ASUS laptops
Comment 41 flyingnu 2012-01-30 13:07:12 UTC
here things partially work with the patch: but i have to use hda-analyzer to change VREF's value when i plug or un-plug headphones.
Comment 42 Takashi Iwai 2012-01-30 13:21:12 UTC
OK, could you try the next one instead?
Comment 43 Takashi Iwai 2012-01-30 13:21:58 UTC
Created attachment 72234 [details]
Patch to apply the VREF-fix for ASUS laptops (v3)
Comment 44 Takashi Iwai 2012-01-30 15:29:11 UTC
Created attachment 72235 [details]
Patch to apply the VREF-fix for ASUS laptops (v4)

Yet more revised patch; add a flag not to override the vref
Comment 45 flyingnu 2012-01-30 16:29:28 UTC
ok problem fixed for my laptop.

Thanks a lot for the help
Comment 46 Takashi Iwai 2012-01-30 17:22:22 UTC
Thanks for testing.  I merged the patch in comment 44 in the upstream tree.
Comment 47 Tom D. 2012-01-31 11:26:16 UTC
After patching latest v4 against 3.2.2 sound and mic (magically) working on asus_laptop A6rp. 
Closing as RESOLVED. Thanks for help!
Comment 48 Florian Mickler 2012-02-01 21:02:44 UTC
A patch referencing this bug report has been merged in Linux v3.3-rc2:

commit 3b25eb690e8c7424eecffe1458c02b87b32aa001
Author: Takashi Iwai <tiwai@suse.de>
Date:   Wed Jan 25 09:55:46 2012 +0100

    ALSA: hda - Fix silent output on ASUS A6Rp
Comment 49 flyingnu 2012-02-08 08:42:02 UTC
hi,

little issue that i didn't notice the first time.

When VREF's value of 0x0f is not equal to HIZ a red light come out from the headphone's jack (example image here http://farm3.staticflickr.com/2068/2227484291_93fd139589_z.jpg) and it never turns off.
Comment 50 Takashi Iwai 2012-02-08 08:56:07 UTC
(In reply to comment #49)
> hi,
> 
> little issue that i didn't notice the first time.
> 
> When VREF's value of 0x0f is not equal to HIZ a red light come out from the
> headphone's jack (example image here
> http://farm3.staticflickr.com/2068/2227484291_93fd139589_z.jpg) and it never
> turns off.

It must be an optical SPDIF output.  You should be able to turn it on/off via "IEC958" mute switch.
Comment 51 flyingnu 2012-02-08 08:59:14 UTC
ops you're right thanks.
Comment 52 Florian Mickler 2012-02-11 15:25:22 UTC
A patch referencing this bug report has been merged in Linux v3.3-rc3:

commit 31150f2327cbb66363f38e13ca1be973d2f9203a
Author: Takashi Iwai <tiwai@suse.de>
Date:   Mon Jan 30 10:54:08 2012 +0100

    ALSA: hda - Apply 0x0f-VREF fix to all ASUS laptops with ALC861/660

Note You need to log in before you can comment on or make changes to this bug.