Bug 207553 - [AMD] Family 17h (Models 10h-1fh) HD Audio Controller [1022:15e3] ALC294 not fully initialised
Summary: [AMD] Family 17h (Models 10h-1fh) HD Audio Controller [1022:15e3] ALC294 not ...
Status: RESOLVED CODE_FIX
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: 2020-05-03 09:59 UTC by Alexey Kuznetsov
Modified: 2020-05-12 08:17 UTC (History)
2 users (show)

See Also:
Kernel Version: 5.4.0-26-generic
Tree: Mainline
Regression: No


Attachments
Test fix patch (1.44 KB, patch)
2020-05-07 13:08 UTC, Takashi Iwai
Details | Diff
fix_alsa_demo (1.88 KB, patch)
2020-05-09 20:45 UTC, Alexey Kuznetsov
Details | Diff
fix_alsa_debian (1.27 KB, patch)
2020-05-11 14:28 UTC, Alexey Kuznetsov
Details | Diff
Submitted patch (2.25 KB, patch)
2020-05-12 07:35 UTC, Takashi Iwai
Details | Diff

Description Alexey Kuznetsov 2020-05-03 09:59:42 UTC
Hello!

Recent windows drivers initialise [1022:15e3]/ALC294 with 24bit 48000HZ, after rebooting to linux it produce garbaged sound (it decay every second, very strange effect). If you reboot from windows 10 1909 directly to linux it broken. You have to turn power off complete to reset the device.

http://alsa-project.org/db/?f=6d80e374011ccba05d32c8a6e6bde57316cbf06d

Long version: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1876459
Comment 1 Takashi Iwai 2020-05-06 14:23:35 UTC
Could you get any differences in alsa-info.sh outputs between working and non-working cases?

At best, add dump_coef=1 option to snd-hda-codec module beforehand and get alsa-info.sh outputs.  This will include the secret register dumps.
Comment 2 Alexey Kuznetsov 2020-05-06 14:40:40 UTC
Thank you for guidness. It is differ:

95c95
<                       HD-Audio Generic at 0xfe7c8000 irq 72
---
>                       HD-Audio Generic at 0xfe7c8000 irq 70
97c97
<                       HD-Audio Generic at 0xfe7c0000 irq 73
---
>                       HD-Audio Generic at 0xfe7c0000 irq 71
301c301
<   Converter: stream=5, channel=0
---
>   Converter: stream=0, channel=0
313c313
<   Converter: stream=5, channel=0
---
>   Converter: stream=0, channel=0
323c323
<   Converter: stream=5, channel=0
---
>   Converter: stream=0, channel=0
597c597
<     Coeff 0x1b: 0x4e4b
---
>     Coeff 0x1b: 0x4a4b
612c612
<     Coeff 0x2a: 0x0000
---
>     Coeff 0x2a: 0x0200
628c628
<     Coeff 0x3a: 0x0010
---
>     Coeff 0x3a: 0x003a
634c634
<     Coeff 0x40: 0x8800
---
>     Coeff 0x40: 0x88f0
732,740c732,740


Not working: http://alsa-project.org/db/?f=595bdd14ac12823b46ac3a5f6820385d05e19802
Comment 3 Alexey Kuznetsov 2020-05-06 14:42:13 UTC
Working configuration (with coefs info): http://alsa-project.org/db/?f=3f15a47699315536f8ae50d41471f98a3e125c4d
Comment 4 Alexey Kuznetsov 2020-05-06 14:45:40 UTC
Also I had to use this hack to make volume working: https://wiki.archlinux.org/index.php/ASUS_Zenbook_UX390

And I notice much higher volume on windows, then on linux. Maybe new settings are better.
Comment 5 Takashi Iwai 2020-05-06 14:51:31 UTC
You can try to set up the COEF verb manually via hda-verb, e.g. for setting the coef 0x1b 0x4a4b,

  hda-verb /dev/snd/hwC1D0 0x20 SET_COEF_INDEX 0x1b
  hda-verb /dev/snd/hwC1D0 0x20 SET_PROC_COEF 0x4a4b
Comment 6 Alexey Kuznetsov 2020-05-06 15:22:18 UTC
0x1b 0x4e4b works!

hda-verb /dev/snd/hwC1D0 0x20 SET_COEF_INDEX 0x1b
hda-verb /dev/snd/hwC1D0 0x20 SET_PROC_COEF 0x4e4b
Comment 7 Takashi Iwai 2020-05-06 16:13:34 UTC
Good to hear.

Kailang, could you check what bit is needed for this laptop?
Comment 8 Kailiang Yang 2020-05-07 05:41:24 UTC
Hi Takashi,

Default value was 0x4e4b.
Maybe Windows driver want to avoid pop noise.
So,let bit 10 to 0.
Comment 9 Alexey Kuznetsov 2020-05-07 08:03:49 UTC
I guess you do not have docs for that hardware? I do not think it is "pop noise" related. I'll upload video to show how it sounds. It's like cassette player chew you tape. My guess still the same - it is related to bits or HZ. Here it goes:

https://www.youtube.com/watch?v=xhFJlrUf3yA
Comment 10 Takashi Iwai 2020-05-07 08:07:48 UTC
The magic COEF bits are never published, unfortunately, AFAIK; it's a vendor-specific thing, after all.

Was it only this COEF verb?  You can change the different values (between 4a4b and 4e4b) back and forth, and confirm whether this alone suffices for fixing your problem.

Once after confirmed, I can cook up a patch to apply the quirk in the driver.
Comment 11 Alexey Kuznetsov 2020-05-07 08:48:13 UTC
Just this one.
Comment 12 Takashi Iwai 2020-05-07 13:05:28 UTC
OK, then could you try the patch below?
Comment 13 Takashi Iwai 2020-05-07 13:08:34 UTC
Created attachment 288977 [details]
Test fix patch
Comment 14 Alexey Kuznetsov 2020-05-08 19:55:25 UTC
For last two days I had issues building and running debian kernel, never face anything like that on ubuntu. Applying this patch manually, not changing anything. After I get back from windows alsa-info shows 0x1b==0x4a4b. I can't be 100% is is not my fault but are you sure this patch should be enough?
Comment 15 Takashi Iwai 2020-05-09 07:07:15 UTC
That's *my* question.  The patch simply adds the COEF setup on top of the default setup, and that's the only requirement you mentioned in comment 11.

I guess you'd better investigate more on other COEFs too.
Comment 16 Alexey Kuznetsov 2020-05-09 07:42:30 UTC
I'm sure calling "hda-verb /dev/snd/hwC1D0 0x20 SET_COEF_INDEX 0x1b; hda-verb /dev/snd/hwC1D0 0x20 SET_PROC_COEF 0x4e4b" is enough. And right now, building kernel with manually applied patch to the current source directory, has no effect on 0x1b coef. Maybe debian configs are missing some CONFIG_ or maybe new debian builds requires put patches into debian/patches and it is mandatory? I guess this is all going to investigate how to build debian kernel.

I guess something wrong with default debian configs/build instructions. Following recommended handbook fails in many ways (you can't apply commands in the handbook order they suggest, because they fail):

https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s-common-official

I tried to "strings ./5.5.0-0.bpo.2-amd64/kernel/sound/pci/hda/snd-hda-codec-realtek.ko" to confirm new "ASUS UX431DA" exists, but here is "ASUS" strings at all in the module. So, very hopeless... but I'm trying different approaches...

I've checked necessary CONFIG_ and they are (more?):

CONFIG_PCI=y
CONFIG_PCI_QUIRKS=y

And putting fix_alsa.patch into debian/patches/debian/fix_alsa_1b.patch and instead recommended:

fakeroot debian/rules binary

I'm using:

debuild -b -uc -us

BTW it takes 35GB free same and a few hours to complete, every try! It used to be few times faster and takes less GB, with other distros at least...
Comment 17 Alexey Kuznetsov 2020-05-09 07:46:53 UTC
I guess this two also important:

CONFIG_SND_HDA_PATCH_LOADER=y
CONFIG_SND_HDA_CODEC_REALTEK=m
Comment 18 Alexey Kuznetsov 2020-05-09 17:55:15 UTC
I rebuild ubuntu kernel (5.4.0-29_5.4.0-29.33) many ways and no luck. After reboot from windows 0x1B==0x4a4b persistent. My guess your patch code never get executed. Missing CONFIG_ or additional patch...
Comment 19 Alexey Kuznetsov 2020-05-09 20:45:43 UTC
Created attachment 289035 [details]
fix_alsa_demo

I even add all coefs into patch. It is no effect. Also I changed module description to see if changes actually affect the module and it did affect the description:

axet@axet-laptop:~$ modinfo /lib/modules/5.4.0-29-generic/kernel/sound/pci/hda/snd-hda-codec-realtek.ko
filename:       /lib/modules/5.4.0-29-generic/kernel/sound/pci/hda/snd-hda-codec-realtek.ko
description:    Realtek HD-audio codec !!!!222!!!!
license:        GPL

Something wrong with the patch.
Comment 20 Takashi Iwai 2020-05-10 09:58:38 UTC
Not sure what's wrong yet.  Please check whether the newly added quirk is certainly applied, e.g. you can add printk to apply_fixup() function in hda_auto_parser.c.  It might be added to the wrong table or with the wrong ID value, for example.
Comment 21 Alexey Kuznetsov 2020-05-11 12:59:45 UTC
Here is a some values, from my few minutes lookups.

[    6.735910] apply_fixup: ALC294 (null) type:0 addr:0 id:99 action:0 bus:fe7c0000
[    6.738535] apply_fixup: ALC294 (null) type:0 addr:0 id:99 action:1 bus:fe7c0000
[    7.219238] apply_fixup: ALC294 (null) type:0 addr:0 id:99 action:2 bus:fe7c0000
[    7.230525] apply_fixup: ALC294 (null) type:0 addr:0 id:99 action:3 bus:fe7c0000
[   10.546755] apply_fixup: ALC294 (null) type:0 addr:0 id:99 action:2 bus:fe7c0000
[   21.406785] apply_fixup: ALC294 (null) type:0 addr:0 id:99 action:2 bus:fe7c0000


printk(KERN_ERR "apply_fixup: %s %s type:%x addr:%x id:%x action:%x bus:%x\n", codec->core.chip_name, modelname, fix->type, codec->addr, id, action, codec->bus->core.addr);
Comment 22 Alexey Kuznetsov 2020-05-11 13:00:19 UTC
[    6.664082] snd_hda_intel 0000:03:00.1: Handle vga_switcheroo audio client
[    6.722868] snd_hda_intel 0000:03:00.1: bound 0000:03:00.0 (ops amdgpu_dm_audio_component_bind_ops [amdgpu])
[    6.735915] snd_hda_codec_realtek hdaudioC1D0: ALC294: Invalid fixup !!! type 0
[    6.736237] snd_hda_codec_realtek hdaudioC1D0: autoconfig for ALC294: line_outs=2 (0x14/0x17/0x0/0x0/0x0) type:speaker
[    6.736239] snd_hda_codec_realtek hdaudioC1D0:    speaker_outs=0 (0x0/0x0/0x0/0x0/0x0)
[    6.736241] snd_hda_codec_realtek hdaudioC1D0:    hp_outs=1 (0x21/0x0/0x0/0x0/0x0)
[    6.736242] snd_hda_codec_realtek hdaudioC1D0:    mono: mono_out=0x0
[    6.736244] snd_hda_codec_realtek hdaudioC1D0:    inputs:
[    6.736246] snd_hda_codec_realtek hdaudioC1D0:      Mic=0x12
[    6.742721] snd_hda_codec_realtek hdaudioC1D0: ALC294: Invalid fixup !!! type 0
[    7.224878] snd_hda_codec_realtek hdaudioC1D0: ALC294: Invalid fixup !!! type 0
[    7.233096] snd_hda_codec_realtek hdaudioC1D0: ALC294: Invalid fixup !!! type 0
[   10.546762] snd_hda_codec_realtek hdaudioC1D0: ALC294: Invalid fixup !!! type 0
[   21.406795] snd_hda_codec_realtek hdaudioC1D0: ALC294: Invalid fixup !!! type 0
Comment 23 Takashi Iwai 2020-05-11 13:28:50 UTC
(In reply to Alexey Kuznetsov from comment #21)
> Here is a some values, from my few minutes lookups.
> 
> [    6.735910] apply_fixup: ALC294 (null) type:0 addr:0 id:99 action:0
> bus:fe7c0000
....
> 
> printk(KERN_ERR "apply_fixup: %s %s type:%x addr:%x id:%x action:%x
> bus:%x\n", codec->core.chip_name, modelname, fix->type, codec->addr, id,
> action, codec->bus->core.addr);

So it's type 0 and id 99, which show a completely bogus entry.
Did you apply the patch properly to the clean latest upstream tree?  It can't break things so much.

Also you didn't pass "patch" module option for snd-hda-intel, right?
Comment 24 Alexey Kuznetsov 2020-05-11 13:54:21 UTC
Right, no options, my defaults/grub is "" ...

On debian my exact steps:

apt source linux
cd linux-5.5.17/
fakeroot debian/rules clean
patch -p2 < ../fix_alsa_1b.patch
dch -laxet # then make it proper looking changelog
fakeroot debian/rules binary # about 34 GB and few hours

On ubuntu the last line is:

fakeroot debian/rules binary-headers binary-generic binary-perarch # about 20GB and an hour

debian install:

sudo dpkg -i linux-image-5.5.0-0.bpo.2-amd64-unsigned_5.5.17-1~bpo10+1axet1_amd64.deb  linux-headers-5.5.0-0.bpo.2-amd64_5.5.17-1~bpo10+1axet1_amd64.deb  linux-headers-5.5.0-0.bpo.2-common_5.5.17-1~bpo10+1axet1_all.deb linux-kbuild-5.5_5.5.17-1~bpo10+1axet1_amd64.deb  linux-compiler-gcc-8-x86_5.5.17-1~bpo10+1axet1_amd64.deb
Comment 25 Takashi Iwai 2020-05-11 14:23:20 UTC
The patch shouldn't be applicable cleanly with 5.5.y code base.
It means that you must have modified the patch...

At best please test with the latest upstream code, i.e. 5.7-rc5.
Comment 26 Alexey Kuznetsov 2020-05-11 14:28:58 UTC
Created attachment 289079 [details]
fix_alsa_debian

Ok, I'll try recent kernel, I'm afraid it may have issues with hardware.

fix_alsa_demo.patch was for ubuntu. Here the same one for debian I'm using
Comment 27 Takashi Iwai 2020-05-11 14:48:42 UTC
Your patch is applied to a wrong place.  The hda_fixup entry should have been added to alc269_fixups[] while yours is applied to alc861_fixups[].  That's why the type=0 is reported; because the quirk ID entry itself is put to the right place while hda_fix entry is missing, it points to the empty slot.
Comment 28 Alexey Kuznetsov 2020-05-11 14:54:26 UTC
Oh, that explains everything! Thanks! 3 days and 50 kernel rebuilds!

For now let's wait 5.7 results :)
Comment 29 Alexey Kuznetsov 2020-05-11 15:19:21 UTC
kernel 5.7 takes 20m, 3GB to build. It stuck at:

[    3.603994] usb 3-2.3: Manufacturer: ELAN

Never booth further. I'll try debian kernel again with properly applied patch.
Comment 30 Alexey Kuznetsov 2020-05-11 20:16:16 UTC
it took 4.8 hours and 34GB to make a debian kernel. Patch works! Thanks for support and fun :D
Comment 31 Takashi Iwai 2020-05-12 07:34:12 UTC
Good to hear.  The patch has been submitted to upstream and merged now.
Comment 32 Takashi Iwai 2020-05-12 07:35:30 UTC
Created attachment 289089 [details]
Submitted patch
Comment 33 Takashi Iwai 2020-05-12 07:36:27 UTC
The fix will be included in the next pull request to 5.7-rc6, and backported to stable kernels later.  Let's close.
Comment 34 Alexey Kuznetsov 2020-05-12 08:17:25 UTC
This notebook also requires to modify /usr/share/pulseaudio/alsa-mixer/paths/analog-output.conf.common for volume to work. Maybe it can be patched as well. It is another bug, not kernel, userspace one. I'm not sure where to ask, here is what's need to do: https://wiki.archlinux.org/index.php/ASUS_Zenbook_UX390

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