Bug 195457 - Realtek ALC295 still unsupported
Summary: Realtek ALC295 still unsupported
Status: NEW
Alias: None
Product: Drivers
Classification: Unclassified
Component: Sound(ALSA) (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: Jaroslav Kysela
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-04-19 04:16 UTC by natedaswas
Modified: 2021-02-19 18:13 UTC (History)
15 users (show)

See Also:
Kernel Version: 4.5
Subsystem:
Regression: No
Bisected commit-id:


Attachments
diff output, two columns (258.68 KB, text/plain)
2017-06-25 05:23 UTC, someidiot128
Details
Test fix patch (850 bytes, patch)
2017-12-18 16:11 UTC, Takashi Iwai
Details | Diff

Description natedaswas 2017-04-19 04:16:17 UTC
A patch was previously submitted to support this sound card and the card is still being reported as not working.

https://patchwork.kernel.org/patch/9142225/

And here are open issues documenting the problem, primarily with users of ubuntu

https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1648183

Seems to be a kernel problem. If it helps users report that if they are dual booting and boot to windows before restarting then they don't experience the problem are the symptoms change.
Comment 1 Takashi Iwai 2017-04-19 06:29:34 UTC
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"
Comment 2 robertjjoynt 2017-04-27 16:53:55 UTC
(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.
Comment 3 Takashi Iwai 2017-04-28 13:31:35 UTC
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.
Comment 4 robertjjoynt 2017-04-29 14:37:49 UTC
(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
Comment 5 robertjjoynt 2017-05-17 15:32:21 UTC
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.
Comment 6 Takashi Iwai 2017-05-17 16:06:05 UTC
Thanks for spotting.

Kailang, is this coef missing for ALC295 setup in general?
Comment 7 Kailiang Yang 2017-05-18 06:36:00 UTC
I need to check with windows code.
Maybe it need to write 0x67 after resume.
Comment 8 Sachin S Kamath 2017-06-13 12:28:00 UTC
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
Comment 9 someidiot128 2017-06-25 05:23:54 UTC
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.
Comment 10 someidiot128 2017-08-01 06:05:45 UTC
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.
Comment 11 Frédéric Pierret 2017-09-06 12:07:33 UTC
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.
Comment 12 Frédéric Pierret 2017-09-06 12:14:41 UTC
Sorry, I made a mistake in posting in the wrong page. It was for explaining to an another bug report.
Comment 13 Marius Nestor 2017-09-20 01:40:23 UTC
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)?
Comment 14 Nate Graham 2017-12-18 15:58:58 UTC
The script worked for me too with an HP Spectre x360 13-w013dx. How do we get this integrated into a kernel fix?
Comment 15 Takashi Iwai 2017-12-18 16:11:22 UTC
Could you try the test patch below?
Comment 16 Takashi Iwai 2017-12-18 16:11:44 UTC
Created attachment 261243 [details]
Test fix patch
Comment 17 Pablo Cholaky 2017-12-26 14:20:44 UTC
(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
Comment 18 Takashi Iwai 2017-12-27 08:08:01 UTC
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.
Comment 19 Paul Menzel 2018-01-18 10:34:00 UTC
This change might have slowed down suspend, so I reported bug 198503 [1].

[1] https://bugzilla.kernel.org/show_bug.cgi?id=198503
Comment 21 mahsoom.moosa42 2019-08-25 09:50:50 UTC
Has this change been reflected on the stable linux kernel? I'm on 5.0.0-25 generic and it still persists.
Comment 23 SaGrLand 2020-12-07 23:23:23 UTC
(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
Comment 24 Paul Menzel 2020-12-08 08:02:19 UTC
(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.
Comment 25 Takashi Iwai 2020-12-08 10:13:20 UTC
(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.
Comment 26 crysman 2021-01-23 14:29:11 UTC
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
Comment 27 crysman 2021-01-23 14:53:30 UTC
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 :(
Comment 28 robertjjoynt 2021-01-31 06:28:22 UTC
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.
Comment 29 crysman 2021-02-02 18:33:31 UTC
@robertjjoynt negative, the second paragraph only made internal speaker not functional and has *not* fixed cable jack mic working :(

(Spin SP513-54N)
Comment 30 crysman 2021-02-19 09:20:22 UTC
Hello, any chance to get this fixed? How may I help to move this forward? I will gladly help, if I know how...
Comment 31 Paul Menzel 2021-02-19 09:26:58 UTC
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
Comment 32 Takashi Iwai 2021-02-19 11:39:25 UTC
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.
Comment 33 Takashi Iwai 2021-02-19 11:43:08 UTC
(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.
Comment 34 crysman 2021-02-19 18:13:56 UTC
I see, thanks, I've created a new issue:
https://bugzilla.kernel.org/show_bug.cgi?id=211853

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