Bug 195457

The subject is misleading.  The codec *is* supported.

Try to turn off the analog-loopback.  It often causes such a noise problem, and it is already turned off as default.
  % amixer -c0 set "Loopback Mixing" "Disabled"

(In reply to Takashi Iwai from comment #1)
> The subject is misleading.  The codec *is* supported.
> 
> Try to turn off the analog-loopback.  It often causes such a noise problem,
> and it is already turned off as default.
>   % amixer -c0 set "Loopback Mixing" "Disabled"

I turned off the analog-loopback, but the problem still persists.

If Windows boot helped, it means that COEF or some vendor-specific stuff is needed.  The best is ask to h/w vendor to send the fix.

If it's not possible, you can try to figure out by comparing the codec proc file in both working and non-working cases.  Pass dump_coef=1 to snd-hda-codec module, then it'll dump the current COEF values.

(In reply to Takashi Iwai from comment #3)
> If Windows boot helped, it means that COEF or some vendor-specific stuff is
> needed.  The best is ask to h/w vendor to send the fix.
> 
> If it's not possible, you can try to figure out by comparing the codec proc
> file in both working and non-working cases.  Pass dump_coef=1 to
> snd-hda-codec module, then it'll dump the current COEF values.

Thanks for your guidance. I followed your instructions and found 8 Coeff differences between the Working Case and Non-working Case. I have contacted HP and have reported my findings and requested a fix.

I have included my findings (below) in case it is useful... 

Cases:

I compared data for three cases as follows:

Working Case: Boot into Linux after booting into Windows 10. Audio works fine.

Non-working Case 1: Boot into Linux from power on. Crackling audio on headphones.

Non-working Case 2:  Boot into Linux after booting into Windows 10. Then suspend and resume. Crackling audio on headphones.



Findings:

The proc differences between Working Case and Non-Working Case 1 consists of 8 Coeff values (no other differences) as follows:



$ diff proc-working.txt proc-nonworking-1.txt
265c265
<     Coeff 0x08: 0x6a0c
---
>     Coeff 0x08: 0x6a8c
270c270
<     Coeff 0x0d: 0xa02f
---
>     Coeff 0x0d: 0xa023
273c273
<     Coeff 0x10: 0x0120
---
>     Coeff 0x10: 0x0020
312c312
<     Coeff 0x37: 0xfe15
---
>     Coeff 0x37: 0xfe05
326,327c326,327
<     Coeff 0x45: 0xd689
<     Coeff 0x46: 0x00f4
---
>     Coeff 0x45: 0x5289
>     Coeff 0x46: 0x0af4
330c330
<     Coeff 0x49: 0x0249
---
>     Coeff 0x49: 0x0049
360c360
<     Coeff 0x67: 0x3000
---
>     Coeff 0x67: 0xf287


Non-working Case 2 had the same 8 Coeff differences from the Working Case (see above). There were some additional differences between the Working Case and the Non-Working Case 2. The following are the additional differences:

$ diff proc-nonworking-1.txt proc-nonworking-2.txt
77c77
<   Converter: stream=1, channel=0
---
>   Converter: stream=0, channel=0
84c84
<   Power: setting=D0, actual=D0
---
>   Power: setting=D3, actual=D3
202c202
<   Power: setting=D0, actual=D0
---
>   Power: setting=D3, actual=D3


alsa-info output shows that the converter stream and first power setting differences (lines 77,84) are under the heading “Node 0x08 [Audio Input] wcaps 0x10051b: Stereo Amp-In”. The second power setting difference (line 202) is under the heading “Node 0x19 [Pin Complex] wcaps 0x40048b: Stereo Amp-In” 

Here are links to the alsa-info output for the three cases (each includes all Coeff values):

Working Case – alsa-info output:
http://www.alsa-project.org/db/?f=86cfcee19a88ab131111d1989038ee1d80fc15b4

Non-working Case 1 – alsa-info output:
http://www.alsa-project.org/db/?f=e3b6bc60eb5086d3b0485b21f8512d30d1e37885

Non-working Case 2 – alsa-info output:
http://www.alsa-project.org/db/?f=f85a7dadac5d1b2d8be5323d930f3e99064e045a

I've managed to fix the problem on my machine. I isolated the problem to a single coeff value (see above). To fix the problem I set the coeff 0x67 to 0x3000.

The following commands fix the problem immediately on my machine (run as root):

hda-verb /dev/snd/hwC0D0 0x20 SET_COEF_INDEX 0x67
hda-verb /dev/snd/hwC0D0 0x20 SET_PROC_COEF 0x3000

I put these commands into a script and used cron with @reboot to run on startup. I copied the script to /lib/systemd/system-sleep to run script on resume from suspend.

Thanks for spotting.

Kailang, is this coef missing for ALC295 setup in general?

I need to check with windows code.
Maybe it need to write 0x67 after resume.

I can confirm that (In reply to robertjjoynt from comment #5)
> I've managed to fix the problem on my machine. I isolated the problem to a
> single coeff value (see above). To fix the problem I set the coeff 0x67 to
> 0x3000.
> 
> The following commands fix the problem immediately on my machine (run as
> root):
> 
> hda-verb /dev/snd/hwC0D0 0x20 SET_COEF_INDEX 0x67
> hda-verb /dev/snd/hwC0D0 0x20 SET_PROC_COEF 0x3000
> 
> I put these commands into a script and used cron with @reboot to run on
> startup. I copied the script to /lib/systemd/system-sleep to run script on
> resume from suspend.

This fix works for me. +1

Created attachment 257171 [details]
diff output, two columns

robertjjoynt's fix doesn't seem to be working for me. The file I've attached is two-column diff output, with the alsa-info output from the working case on the left and output of the same command on my machine. In my case, there are no coefficients to set.

Okay, everything bar the subwoofer in my laptop isn't working. This particular laptop is a 'Pavilion 15-aw054sa' and I'm running Linux Mint Sonya; despite the upgrade nothing has changed.

Hi,

I also had the same problem with my ASROCK X370 Gaming K4 (ALC1220):

1st case: Booting FIRST Linux: Sound with noise/crackling.
2nd case: Booting FIRST Windows and SECOND Linux: Sound is perfect.

I suceed in solving the problem by comparing the Coeff values in both cases and assign the values of the second case in a script at boot time. How to:

- Install alsa-tools.
- In both cases, you have to: echo 1 > /sys/module/snd_hda_codec/parameters/dump_coefs
- Then, in the first case,  alsa-info --no-upload --output infos_bad
- Then, in the second case, alsa-info --no-upload --output infos_good
- Finally, you compare the coef values: diff infos_bad infos_good | grep Coeff

For changing the value of each different Coeff, you need to proceed as follow: for example, changing Coeff 0x67 to value 0x3000

hda-verb /dev/snd/hwC0D0 0x20 SET_COEF_INDEX 0x67
hda-verb /dev/snd/hwC0D0 0x20 SET_PROC_COEF 0x3000

You have to do this in the growing order of Coeff. Remark that hwC0D0 refers to your sound card. In case of HDMI output like me, my sound card if hwC1D0.

Here is a quick script:

------------------------------------------------------------------------
#!/bin/bash

coeffs=($(echo 0x{16,43,44,5d,5e,63,67}))
values=($(echo 0x{8020,3405,fa10,0606,0000,e430,3000}))

for i in `seq 0 $(( ${#coeffs[@]} - 1 ))`
do
	hda-verb /dev/snd/hwC1D0 0x20 SET_COEF_INDEX ${coeffs[$i]} && hda-verb /dev/snd/hwC1D0 0x20 SET_PROC_COEF ${values[$i]}
done
------------------------------------------------------------------------

Just change the coeffs to change in the array 'coeffs' and the new values in array 'values' and exec this script. A remark, while I do not shutdown the power supply, my audio chipset keeps the values. This is why you need to do the FIRST case (first...) and then the second. Then, you could test if it works only when you shutdown the power supply of your mobo and then booting into Linux directly.

I'm preparing a patch for the kernel but for those who have the problem, could you post your coeff/values which need to be change please.

Hope this helps.

Sorry, I made a mistake in posting in the wrong page. It was for explaining to an another bug report.

I confirm robertjjoynt's workaround fixes the issue. My laptop is a HP Pavilion x360 Convertible 13-u103nq (Codec: Realtek ALC295) running Ubuntu 17.10 (Artful Aardvark) with Linux kernel 4.12.13. Is this bug fixed in a newer kernel version (e.g. Linux 4.13.x or Linux 4.14-rc1)?

The script worked for me too with an HP Spectre x360 13-w013dx. How do we get this integrated into a kernel fix?

Could you try the test patch below?

Created attachment 261243 [details]
Test fix patch

(In reply to Takashi Iwai from comment #16)
> Created attachment 261243 [details]
> Test fix patch

Patch works great for me with 4.15.0-rc5. Now I have volumes at correct volume with headphones and no need of using hda-verb.

Hardware:
- Device: ASUS Zephyrus
- Audio: Intel CM238, using module snd_hda_codec_realtek

OK, submitted and merged the fix patch to sound git tree.
It'll be included in the next pull request to Linus, and backported to stable kernels later.

This change might have slowed down suspend, so I reported bug 198503 [1].

[1] https://bugzilla.kernel.org/show_bug.cgi?id=198503

Has this change been reflected on the stable linux kernel? I'm on 5.0.0-25 generic and it still persists.

(In reply to robertjjoynt from comment #5)
> I've managed to fix the problem on my machine. I isolated the problem to a
> single coeff value (see above). To fix the problem I set the coeff 0x67 to
> 0x3000.
> 
> The following commands fix the problem immediately on my machine (run as
> root):
> 
> hda-verb /dev/snd/hwC0D0 0x20 SET_COEF_INDEX 0x67
> hda-verb /dev/snd/hwC0D0 0x20 SET_PROC_COEF 0x3000
> 
> I put these commands into a script and used cron with @reboot to run on
> startup. I copied the script to /lib/systemd/system-sleep to run script on
> resume from suspend.

The Fix worked for me: ThinkPad X1 Carbon 8th Gen, Fedora 33, 5.9.11-200

(In reply to SaGrLand from comment #23)

[…]

> The Fix worked for me: ThinkPad X1 Carbon 8th Gen, Fedora 33, 5.9.11-200

Takashi, it looks like the problem still persists.

(In reply to Paul Menzel from comment #24)
> (In reply to SaGrLand from comment #23)
> 
> […]
> 
> > The Fix worked for me: ThinkPad X1 Carbon 8th Gen, Fedora 33, 5.9.11-200
> 
> Takashi, it looks like the problem still persists.

Could you specify which machine are you referring to?  It's better to create another report, as this bug entry got spammed.

Hello, this bug might be related to external microphone not working issue, right? 

I've asked both here:
- https://askubuntu.com/questions/1305942/external-headset-microphone-not-working-in-ubuntu-20-10-not-even-wired-cable-h

and here:
- https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1912052

but no luck so far :/

What am I supposed to do in order to fix it, please?

I've got ACER Spin 5 (SP513-54N) with Ubuntu 20.10.

Thanks a lot #crysman

I've tried this:
```
sudo apt install alsa-tools
hda-verb /dev/snd/hwC0D0 0x20 SET_COEF_INDEX 0x67
hda-verb /dev/snd/hwC0D0 0x20 SET_PROC_COEF 0x3000
```

output:
```
$ sudo hda-verb /dev/snd/hwC0D0 0x20 SET_COEF_INDEX 0x67
nid = 0x20, verb = 0x500, param = 0x67
value = 0x0
```

and

```
$ sudo hda-verb /dev/snd/hwC0D0 0x20 SET_PROC_COEF 0x3000
nid = 0x20, verb = 0x400, param = 0x3000
value = 0x0
```

Unfortunately, this has not helped to fix the mic :(

I've found another issue with the Realtek ALC295 codec which I also have a fix for.

When I boot into Windows first and then into Linux, there are two problems:

1. The internal speakers don't work (headphones are okay).
2. The internal microphone doesn't respond.

The following commands fix these problems immediately on my machine (run as root):

# Fix for no sound from internal speakers when rebooting from Windows
hda-verb /dev/snd/hwC0D0 0x20 SET_COEF_INDEX 0x10
hda-verb /dev/snd/hwC0D0 0x20 SET_PROC_COEF 0x0120
hda-verb /dev/snd/hwC0D0 0x20 SET_COEF_INDEX 0x0d
hda-verb /dev/snd/hwC0D0 0x20 SET_PROC_COEF 0xa023

# Fix for no mic and headphone jack switching when rebooting from Windows
hda-verb /dev/snd/hwC0D0 0x20 SET_COEF_INDEX 0x45
hda-verb /dev/snd/hwC0D0 0x20 SET_PROC_COEF 0x5289
hda-verb /dev/snd/hwC0D0 0x20 SET_COEF_INDEX 0x46
hda-verb /dev/snd/hwC0D0 0x20 SET_PROC_COEF 0x0004

I put these commands into a script and used cron with @reboot to run on startup. I didn't copy or link the script to /lib/systemd/system-sleep as the fix persists after resume from suspend.

@robertjjoynt negative, the second paragraph only made internal speaker not functional and has *not* fixed cable jack mic working :(

(Spin SP513-54N)

Hello, any chance to get this fixed? How may I help to move this forward? I will gladly help, if I know how...

I’d contact the Linux sound maintainers per email [1].

    M:	Jaroslav Kysela <perex@perex.cz>
    M:	Takashi Iwai <tiwai@suse.com>
    L:	alsa-devel@alsa-project.org (moderated for non-subscribers)


[1]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/MAINTAINERS

No, please don't hang on this bug report unless you have absolutely the same problem as the original bug report.  The codec chip is used for many different machines in various ways, so each model may have a different problem.

(In reply to robertjjoynt from comment #28)
> I've found another issue with the Realtek ALC295 codec which I also have a
> fix for.

For tracking those, could you open another bug report and continue there?  We can made the proper quirk entry for those fixups.  For that, please give the alsa-info.sh output again.

I'm going to close this bug entry for avoiding the confusion.  It's no thread to debug / discuss random bugs that happen to have the same codec chip.  Each specific problem needs to be tracked in the separate bug report instead.

I see, thanks, I've created a new issue:
https://bugzilla.kernel.org/show_bug.cgi?id=211853