Bug 207553

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.

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

Working configuration (with coefs info): http://alsa-project.org/db/?f=3f15a47699315536f8ae50d41471f98a3e125c4d

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.

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

0x1b 0x4e4b works!

hda-verb /dev/snd/hwC1D0 0x20 SET_COEF_INDEX 0x1b
hda-verb /dev/snd/hwC1D0 0x20 SET_PROC_COEF 0x4e4b

Good to hear.

Kailang, could you check what bit is needed for this laptop?

Hi Takashi,

Default value was 0x4e4b.
Maybe Windows driver want to avoid pop noise.
So,let bit 10 to 0.

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

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.

Just this one.

OK, then could you try the patch below?

Created attachment 288977 [details]
Test fix patch

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?

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.

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

I guess this two also important:

CONFIG_SND_HDA_PATCH_LOADER=y
CONFIG_SND_HDA_CODEC_REALTEK=m

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

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.

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.

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

[    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

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

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

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.

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

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.

Oh, that explains everything! Thanks! 3 days and 50 kernel rebuilds!

For now let's wait 5.7 results :)

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.

it took 4.8 hours and 34GB to make a debian kernel. Patch works! Thanks for support and fun :D

Good to hear.  The patch has been submitted to upstream and merged now.

Created attachment 289089 [details]
Submitted patch

The fix will be included in the next pull request to 5.7-rc6, and backported to stable kernels later.  Let's close.

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