You are not logged in.
I am on the way to create a patch for my laptop to have the speakers working, but I got stuck at the patch and it starts to drive me crazy now.
The story so far:
I have sound using the lts kernel and applying one of the asus models (basically almost any of them)
But I lose it when I am running the latest one.
When I ran
# echo 1 |sudo tee /sys/module/snd_hda_codec/parameters/dump_coef
# cat /proc/asound/card*/codec#0
The difference is that with the latest kernel at Node 0x20 the Coeff 0x0f: 0x7774 as per the lts it is 0x7778.
Also the card now is card2 as before it was card0, but I am not sure if that is relevant.
So when I ran:
# hda-verb /dev/snd/hwC2D0 0x20 0x500 0x0f
# hda-verb /dev/snd/hwC2D0 0x20 0x400 0x7778
Suddenly sound.
I have also tried multiple models in the alsa config, but none of them seemed to work (basically all asus one by one and all with ALC294).
I was thinking to create a patch.
# /proc/asound/card*/codec#0
gives me:
Codec: Realtek ALC294
Address: 0
AFG Function Id: 0x1 (unsol 1)
Vendor Id: 0x10ec0294
Subsystem Id: 0x10431a8e
Revision Id: 0x100004
So the current patch looks like this:
/lib/firmware/alc294-sound-patch.fw
[codec]
0x10ec0294 0x10431a8e 0
[verb]
0x20 0x500 0x0f
0x20 0x400 0x7778
And I have in
/etc/modprobe.d/alsa-base.conf
options snd-hda-intel patch=alc294-sound-patch.fw
No results, the coeff is still 0x7774
The kernel parameters:
CONFIG_SND_HDA_RECONFIG=y
CONFIG_SND_HDA_CODEC_REALTEK=m
What am I doing wrong?
Last edited by stoppos (2024-12-28 09:39:48)
Offline
I am on the way to create a patch for my laptop to have the speakers working, but I got stuck at the patch and it starts to drive me crazy now.
The story so far:
I have sound using the lts kernel and applying one of the asus models (basically almost any of them)
But I lose it when I am running the latest one.When I ran
# echo 1 |sudo tee /sys/module/snd_hda_codec/parameters/dump_coef # cat /proc/asound/card*/codec#0
The difference is that with the latest kernel at Node 0x20 the Coeff 0x0f: 0x7774 as per the lts it is 0x7778.
Also the card now is card2 as before it was card0, but I am not sure if that is relevant.So when I ran:
# hda-verb /dev/snd/hwC2D0 0x20 0x500 0x0f # hda-verb /dev/snd/hwC2D0 0x20 0x400 0x7778
Suddenly sound.
I have also tried multiple models in the alsa config, but none of them seemed to work (basically all asus one by one and all with ALC294).
I was thinking to create a patch.
# /proc/asound/card*/codec#0
gives me:
Codec: Realtek ALC294 Address: 0 AFG Function Id: 0x1 (unsol 1) Vendor Id: 0x10ec0294 Subsystem Id: 0x10431a8e Revision Id: 0x100004
So the current patch looks like this:
/lib/firmware/alc294-sound-patch.fw [codec] 0x10ec0294 0x10431a8e 0 [verb] 0x20 0x500 0x0f 0x20 0x400 0x7778
And I have in
/etc/modprobe.d/alsa-base.conf options snd-hda-intel patch=alc294-sound-patch.fw
No results, the coeff is still 0x7774
The kernel parameters:
CONFIG_SND_HDA_RECONFIG=y CONFIG_SND_HDA_CODEC_REALTEK=m
What am I doing wrong?
Alright, so we know the patch isn’t being applied properly, which obviously is why the coefficient isn’t changing. I'll try to give this a go. First, double-check the patch file itself in /lib/firmware/alc294-sound-patch.fw. It should look exactly like this:
[codec]
0x10ec0294 0x10431a8e 0
[verb]
0x20 0x500 0x0f
0x20 0x400 0x7778
Make sure there aren’t any extra spaces or weird formatting issues. Next, in /etc/modprobe.d/alsa-base.conf, you’ve got the right line:
options snd-hda-intel patch=alc294-sound-patch.fw
After adding it, run:
"sudo mkinitcpio"
If you got more than one kernel add -P to the command. Then reboot and check if it worked by running:
cat /proc/asound/card*/codec#0
If Node 0x20 still shows Coeff 0x0f: 0x7774, then for some weird reason the patch isn’t being applied. Since you’ve already confirmed that manually running hda-verb fixes the sound, you could try automating that as a workaround. Just create a script like this:
#!/bin/bash
hda-verb /dev/snd/hwC2D0 0x20 0x500 0x0f
hda-verb /dev/snd/hwC2D0 0x20 0x400 0x7778
Save it as /usr/local/bin/fix-audio.sh, then make it executable:
sudo chmod +x /usr/local/bin/fix-audio.sh
You can either run this manually after booting or set it to run automatically at startup using a systemd service or your desktop autostart settings. If the patch still isn’t working after all this, it might be an issue with how the newer kernel handles codec patches. In that case, sticking with the LTS kernel for now might be your best bet until there’s a fix upstream. Let me know how it goes.
Offline
Katataf1sh, please don't quote full posts, use multiple quote blocks that match what you respond to .
Moving to kernel & hardware.
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
Thank you,
I've removed all extra spaces, ran mkinitcpio and no change.
I'll make the startup auto fix.
Offline
Katataf1sh, please don't quote full posts, use multiple quote blocks that match what you respond to .
Moving to kernel & hardware.
Yeah, tbh I didn't even realize I've done that until now, I'll refrain from doing that again, cheers.
Offline
Thank you,
I've removed all extra spaces, ran mkinitcpio and no change.
I'll make the startup auto fix.
Let me know how that worked out for you.
Offline
Let me know how that worked out for you.
It helped for a short time, but then it switched back to no sound.
I'll continue to experiment when I have time and update here if I find anything.
I also have this weird feeling that whatever I put in alsa-base.conf is just not picked up. I tried a couple of models, but the dumps remained identical.
Offline
What kernel are you using?
Offline
6.12.1.arch1-1 - This is the one not working.
6.6.63-1-lts - This one works.
Ok, so the conf file is definitely picked up. I just tried to do somehting not possible (switching 2 intel audio cards) and it threw an error.
It is also sure that there is something wrong with my patch, because I just tried to apply it on the LTS kernel and it does not work there either.
Last edited by stoppos (2024-12-21 09:02:57)
Offline
Solution:
Ok, so I had some more time to play with it. I ran alsa-info.sh --no-upload and I saw that the nvidia card was also using the snd_hda_intel and the problem came from the fact which I thought irrelevant, that the 2 cards exchanged places. Nvidia is always card0 and the realtec jumped between card1 and card3.
snd_hda_intel (card 0)
snd_usb_audio (card 1)
snd_hda_intel (card 2)
snd_usb_audio (card 3)
I also found 2 models in the realtek.c file in the linux code which uses 0x7778 for pin 0x20 on nid 0x0f.
So applying
snd_hda_intel: model=1043:1982,1043:1982
solved the issue
Offline