Bug 42588

Created attachment 72084 [details]
alsa-info working 3.1.9

Created attachment 72085 [details]
/proc/asound/devices info

Created attachment 72086 [details]
/proc/asound/cards info

Created attachment 72087 [details]
/proc/asound/pcm info

Created attachment 72089 [details]
Audio device lspci

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?

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

Created attachment 72112 [details]
Alsa-info on 3.2.1 vanilla NOT working sound

Emerge on EXACT same config. No sound

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.

Created attachment 72123 [details]
Alsa-info on 3.2.1 set Auto-Mute Mode=Enabled

Changing the setting. Not played sound yet.

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

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

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?

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.

oh, and cdrom

This is the case: http://git.alsa-project.org/?p=alsa-kernel.git;a=commit;h=cb4e482415a2fd09e75a33516b8578ec6885240d

Good settings is model=asus
It`s for Asus A6rp notebook

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.

Created attachment 72126 [details]
Pins check

It`s wired but there`s nothing. All values 0x7fffffff

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

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.

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.

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?

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.

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.

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.

Created attachment 72153 [details]
A patch to fix 0x0f pin-setup for ASUS A6Rp

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.

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.

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.

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.

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.

Could you check the patch below?  This enables the VREF fix for all ASUS laptops with ALC861/660.

Created attachment 72227 [details]
Patch to apply the VREF-fix for ASUS laptops

(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] = {
               ^^^^^^^^^^^

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

Created attachment 72232 [details]
rejected code from the patch

ehm my fault I didn't see the _VENDOR

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.

Created attachment 72233 [details]
Revised patch to apply the VREF-fix for ASUS laptops

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.

OK, could you try the next one instead?

Created attachment 72234 [details]
Patch to apply the VREF-fix for ASUS laptops (v3)

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

ok problem fixed for my laptop.

Thanks a lot for the help

Thanks for testing.  I merged the patch in comment 44 in the upstream tree.

After patching latest v4 against 3.2.2 sound and mic (magically) working on asus_laptop A6rp. 
Closing as RESOLVED. Thanks for help!

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

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.

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

ops you're right thanks.

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