search

smallcms / asus_zenbook_ux3405ma

SSDT Patch to fix missing speakers sound in Linux on Asus Zenbook 14 UX3405MA (2024) and latest BIOS
22 stars 1 forks source link

Low volume unless kernel audio patch applied #7

Closed paul-ri closed 2 months ago

paul-ri commented 3 months ago

Could you confirm if you have volume issues on your laptop, even with the fix proposed in this repository? I am also not sure if the SSDT patch is properly applied when I try it.

I am able to dual boot in Windows and noticed the volume level is much lower on Linux than on Windows, I'd say around 1/3rd or 1/4th of the maximum volume. The sound quality is also generally not as good (some crackling), and the audio sometimes glitches (metallic noise and playback sometimes freezes). Since I don't have an absolute volume measurement device: By the volume being low, I mean that I never thought "Oh woaw, too loud" at the max volume.

Using a kernel patch from the "Asus Zenbook UX3402 speakers on Linux" thread and compiling the kernel, I'm able to get the right volume level and do not need this repository SSDT patch. Yet the sound quality has issues as above.

I want to start a thread to capture these issues and hopefully find answers.

System info:

Notes:

There's a bunch of further details below where I try the stable kernel vs. mainline kernel compile on the laptop with and without the SSDT patch of this repository.

Thanks for paving the way to fixing these issues!

Summary table

+ sof-firmware
+ SSDT		 - sof-firmware
+ SSDT		 + sof-firmwate
- SSDT		 - sof-firmware
- SSDT
stable kernel Low volume No sound Low volume No sound
mainline kernel
+kernel audio patch		 High volume No sound High volume No sound

Details

Stable Linux, no SSDT file applied

Low volume

Stable Linux + SSDT file in initramfs, but no sof-firmware package

No sound, no soundcards found with aplay -l

Stable Linux + SSDT file in initramfs

Low volume

Mainline Linux + kernel audio patch, no SSDT file applied

High volume

Mainline Linux + kernel audio patch + SSDT file in initramfs + sof-firmware package

High volume

Mainline Linux + kernel audio patch + SSDT file in initramfs but no sof-firmware package

No soundcard

smallcms commented 3 months ago

Hello, @paul-ri ! Try to install Arch package from Build Service. In this package we have optimisations by @r03n About glitches, cracking read my bonus here. I don't have Windows, but how i comprare, what sound is "fixed" (Cirrus is active): run youtube dance music on 100% vol. If you feel vibrations from Zenbook by your hand - all ok. If sound low, whithout little bass - cirrus not active.

UPD: oh, sorry, i see, what AUR package already pull fresh code. This is ok. So, here is only one way, run: grub-mkconfig -o /boot/grub/grub.cfg I'm have Fedora 40, and always use method, like Using the AML with GRUB.

paul-ri commented 3 months ago

In this package we have optimisations

The AUR package indeed includes this one.

About glitches, cracking read my bonus

Thanks! I thought the AUR package was handling all this, but after double checking, it was renaming the .conf to a .lua file. I've sent a patch request to fix this. Locally, this has fixed the issue!

If sound low, whithout little bass - cirrus not active

OK, so you do have high volume. Then it means I'm failing to make this SSDT file work, and I don't know why. Your system is quite different from mine, so it'll be hard to debug. I use systemd-boot boot loader https://wiki.archlinux.org/title/Arch_boot_process#Boot_loader whilst you're using GRUB.

Sounds like there are 2 solutions to this volume problem: your SSDT file, or a kernel patch. Were you aware of this person's patch: https://gist.github.com/lamperez/862763881c0e1c812392b5574727f6ff?permalink_comment_id=5010590#gistcomment-5010590 ?

I'm basically wondering what's the long term fix. What should we ask the kernel folks to change?

smallcms commented 3 months ago

Sounds like there are 2 solutions to this volume problem: your SSDT file, or a kernel patch. Were you aware of this person's patch: https://gist.github.com/lamperez/862763881c0e1c812392b5574727f6ff?permalink_comment_id=5010590#gistcomment-5010590 ?

Yes i seen it, but main idea - is do not compile kernel every time. Also, I don't like solutions like comment "if-else" in parts of drivers:

-   if (!dsd_found) {
+   // if (!dsd_found) {

Let's return to your problem with "Using mkinitcpio's acpi_override hook". Try to double check three steps:

Also, verify. what you have installed package named linux-firmware (here our cirrus drivers).

I'm basically wondering what's the long term fix. What should we ask the kernel folks to change?

In https://github.com/torvalds/linux/blob/master/sound/pci/hda/cs35l41_hda_property.c add our subsystem id 10431A63 (at June 2024 here this id not exists) and CORRECT dsd from cirrus side: https://github.com/CirrusLogic/linux-firmware/tree/main/cirrus The main painful thing is very slow integration code from CirrusLogic to kernel. Zenbook UX3405MA goes from factory with preinstalled "non-linux", so at now we can help oneself only by hacks... :roll_eyes:

r03n commented 2 months ago

A fix has been made by cirrus developers as of July 3 (https://lore.kernel.org/linux-sound/20240703140802.27688-1-sbinding@opensource.cirrus.com/). Can't wait for it to be upstreamed.🎉

paul-ri commented 2 months ago

Yeah I created this issue so it was visible to the Cirrus developers https://bugzilla.kernel.org/show_bug.cgi?id=218991 , my first kernel 'bug' ticket 😄

@smallcms , thanks for the help! I had all things setup the way you suggest as far as I know. I spent too much time debugging the other things so I'll just build a custom kernel until the patch makes its way in now.

matplinta commented 2 months ago

Thank you all for this issue reported - after 2 weeks with my new UX3405, tweaking and searching all the forums about low volume issues, I hope finally my sound will be working correctly! Can you guys hazard a guess when this patch will be upstreamed?

matplinta commented 2 months ago

Is BIOS version 305 necessary for this patch / aur package to work? I am currently on 301, as my laptop came with it. I suffered from the low-volume issue, the crackling noise was not present in my case. I tried the AUR package to mitigate the low-volume issue, however it resulted in losing the sound whatsoever, and actually gave me the crackling noise that wasn't there in the first place. Had to delete the package, reinstall linux-firmware, set the options snd-intel-dspcfg dsp_driver=1 to use the default driver and boot to arch from windows in order to regain the properly working sound (still with low volume). I am only asking as I am hesitant to upgrade BIOS to 305, I read that it resulted in some fan issues for some users. I am on kernel 6.9.7-arch1-1.

smallcms commented 2 months ago

Hello, @matplinta !

Is BIOS version 305 necessary for this patch / aur package to work?

No, this is not BIOS version problem, but we include any important data to help us understand, what is problem.

I am only asking as I am hesitant to upgrade BIOS to 305, I read that it resulted in some fan issues for some users.

And no, fan cooling not problem after upgrade to 305. As for me - i'm using TLP and with youtube on 1080p i'm get these results: On battery: with command list=$(ps --no-headers -fu smallcms | grep -vE 'systemd|wayland-display' | awk '{print $2}'); for pid in $(echo $list); do taskset -pca 18-21 $pid >/dev/null; done;

(last 4 cores of CPU)

tlp-stat -t
--- TLP 1.6.0 --------------------------------------------

+++ Temperatures
CPU temp               =    47 [°C]
Fan speed (fan1)       =     0 [/min]

and on AC adapter: with command list=$(ps --no-headers -fu smallcms | grep -vE 'systemd|wayland-display' | awk '{print $2}'); for pid in $(echo $list); do taskset -pca 0-21 $pid >/dev/null; done;

(all cores of CPU)

tlp-stat -t
--- TLP 1.6.0 --------------------------------------------

+++ Temperatures
CPU temp               =    51 [°C]
Fan speed (fan1)       =  1900 [/min]

*Hint: i use taskset in KDE power settings (as external script in schema) to get about +10 hours to my battery, i dont't like use all CPU when far from charger.

In my case, i don't see any changes with 301 or 304, and it's realy looks like "Optimize system performance" (in their BIOS "changelog", lol).

matplinta commented 2 months ago

Thanks @smallcms for the response! I see, and by any chance do you also dual boot with Windows? I have dual boot with Win11 for work, and Arch for personal use. I suppose the fan issue that affected some users was noticed at Windows's side... However if the problem would be in BIOS version, then it should also be visible on Arch, right?

Anyway, I am wondering why didn't the patch (applied via AUR package installation) work in my case? I am on kernel 6.9.7-arch1-1, with pipewire and wireplumber. Package installed successfully etc. Might I have missed something? I use mkinitcpio, the initramfs was rebuild after the installation etc...

paul-ri commented 2 months ago

@matplinta , I am dual booting Windows too, give a look at the developer's answer on my similar problem as you: https://bugzilla.kernel.org/show_bug.cgi?id=218991#c10 . I had no sound on 1 or 2 speakers at random, but turns out it's when restarting from Windows. I have to cold boot into Linux to have both speakers ON.

With that in mind, that leaves you with the low-volume and the crackling issues to handle : )

smallcms commented 2 months ago

do you also dual boot with Windows?

No, I have only Fedora 40 onboard.

I have to cold boot into Linux to have both speakers ON

Wow, this is strange behavior. Anyway, very sad, what in Arch ssdt fix not helps (like in case with grub), but very glad, what @paul-ri notified kernel and cirrus teams to make fix from kernel and firmware side (this is cool). Very hope, this repo switch as archived soon.

matplinta commented 2 months ago

@paul-ri I followed your bugzilla issue closely, however it all looks very similar yet kind of the opposite, since after applying the patch is only when the sound started crackling and eventually be gone after few seconds of running. As far as I recall I might have originally booted from win to linux, and then subsequently used only reboot command (keep in mind I had fast boot disabled, don't know if it matters) between the linux sessions. I guess rebooting from linux to linux is not the same as "cold boot"?

Additionally, I checked journal logs from the next boot after the patch was installed, I noticed ACPI BIOS errors:

lip 06 13:55:49 AsusZenbookArch kernel: ACPI BIOS Error (bug): Failure creating named object [\_SB.PC00.SPI1.SPK1], AE_ALREADY_EXISTS (20230628/dswload2-326)
lip 06 13:55:49 AsusZenbookArch kernel: fbcon: Taking over console
lip 06 13:55:49 AsusZenbookArch kernel: ACPI Error: AE_ALREADY_EXISTS, During name lookup/catalog (20230628/psobject-220)
lip 06 13:55:49 AsusZenbookArch kernel: ACPI: Skipping parse of AML opcode: Device (0x5B82)
lip 06 13:55:49 AsusZenbookArch kernel: ACPI BIOS Error (bug): Failure creating named object [\_SB.PC00.SPI1._DSD], AE_ALREADY_EXISTS (20230628/dswload2-326)
lip 06 13:55:49 AsusZenbookArch kernel: ACPI Error: AE_ALREADY_EXISTS, During name lookup/catalog (20230628/psobject-220)

Is it normal after applying the patch?

Other relevant logs from journal during that boot:

lip 06 13:55:50 AsusZenbookArch kernel: sof-audio-pci-intel-mtl 0000:00:1f.3: Topology: ABI 3:29:0 Kernel ABI 3:23:0
lip 06 13:55:50 AsusZenbookArch kernel: skl_hda_dsp_generic skl_hda_dsp_generic: ASoC: Parent card not yet available, widget card binding deferred
lip 06 13:55:50 AsusZenbookArch kernel: cs35l41-hda spi1-CSC3551:00-cs35l41-hda.0: Falling back to default firmware.
lip 06 13:55:50 AsusZenbookArch kernel: cs35l41-hda spi1-CSC3551:00-cs35l41-hda.0: DSP1: Firmware version: 3
lip 06 13:55:50 AsusZenbookArch kernel: cs35l41-hda spi1-CSC3551:00-cs35l41-hda.0: DSP1: cirrus/cs35l41-dsp1-spk-prot.wmfw: Fri 24 Jun 2022 14:55:56 GMT Daylight Time
lip 06 13:55:50 AsusZenbookArch kernel: cs35l41-hda spi1-CSC3551:00-cs35l41-hda.0: DSP1: Firmware: 400a4 vendor: 0x2 v0.58.0, 2 algorithms
lip 06 13:55:50 AsusZenbookArch kernel: cs35l41-hda spi1-CSC3551:00-cs35l41-hda.0: DSP1: cirrus/cs35l41-dsp1-spk-prot.bin: v0.58.0
lip 06 13:55:50 AsusZenbookArch kernel: cs35l41-hda spi1-CSC3551:00-cs35l41-hda.0: DSP1: spk-prot: e:\workspace\workspace\tibranch_release_playback_6.76_2\ormis\staging\default_tunings\internal\CS>
lip 06 13:55:50 AsusZenbookArch kernel: cs35l41-hda spi1-CSC3551:00-cs35l41-hda.0: CS35L41 Bound - SSID: 10431A63, BST: 1, VSPK: 1, CH: L, FW EN: 1, SPKID: -19
lip 06 13:55:50 AsusZenbookArch kernel: snd_hda_codec_realtek ehdaudio0D0: bound spi1-CSC3551:00-cs35l41-hda.0 (ops cs35l41_hda_comp_ops [snd_hda_scodec_cs35l41])
lip 06 13:55:50 AsusZenbookArch kernel: cs35l41-hda spi1-CSC3551:00-cs35l41-hda.1: Falling back to default firmware.
lip 06 13:55:50 AsusZenbookArch kernel: cs35l41-hda spi1-CSC3551:00-cs35l41-hda.1: DSP1: Firmware version: 3
lip 06 13:55:50 AsusZenbookArch kernel: cs35l41-hda spi1-CSC3551:00-cs35l41-hda.1: DSP1: cirrus/cs35l41-dsp1-spk-prot.wmfw: Fri 24 Jun 2022 14:55:56 GMT Daylight Time
lip 06 13:55:50 AsusZenbookArch kernel: cs35l41-hda spi1-CSC3551:00-cs35l41-hda.1: DSP1: Firmware: 400a4 vendor: 0x2 v0.58.0, 2 algorithms
lip 06 13:55:50 AsusZenbookArch kernel: cs35l41-hda spi1-CSC3551:00-cs35l41-hda.1: DSP1: cirrus/cs35l41-dsp1-spk-prot.bin: v0.58.0
lip 06 13:55:50 AsusZenbookArch kernel: cs35l41-hda spi1-CSC3551:00-cs35l41-hda.1: DSP1: spk-prot: e:\workspace\workspace\tibranch_release_playback_6.76_2\ormis\staging\default_tunings\internal\CS>
lip 06 13:55:50 AsusZenbookArch kernel: cs35l41-hda spi1-CSC3551:00-cs35l41-hda.1: CS35L41 Bound - SSID: 10431A63, BST: 1, VSPK: 0, CH: R, FW EN: 1, SPKID: -19
lip 06 13:55:50 AsusZenbookArch kernel: snd_hda_codec_realtek ehdaudio0D0: bound spi1-CSC3551:00-cs35l41-hda.1 (ops cs35l41_hda_comp_ops [snd_hda_scodec_cs35l41])
lip 06 13:55:50 AsusZenbookArch kernel: snd_hda_codec_realtek ehdaudio0D0: autoconfig for ALC294: line_outs=1 (0x17/0x0/0x0/0x0/0x0) type:speaker
lip 06 13:55:50 AsusZenbookArch kernel: snd_hda_codec_realtek ehdaudio0D0:    speaker_outs=0 (0x0/0x0/0x0/0x0/0x0)
lip 06 13:55:50 AsusZenbookArch kernel: snd_hda_codec_realtek ehdaudio0D0:    hp_outs=1 (0x21/0x0/0x0/0x0/0x0)
lip 06 13:55:50 AsusZenbookArch kernel: snd_hda_codec_realtek ehdaudio0D0:    mono: mono_out=0x0
lip 06 13:55:50 AsusZenbookArch kernel: snd_hda_codec_realtek ehdaudio0D0:    inputs:
lip 06 13:55:50 AsusZenbookArch kernel: skl_hda_dsp_generic skl_hda_dsp_generic: hda_dsp_hdmi_build_controls: no PCM in topology for HDMI converter 3
lip 06 13:55:50 AsusZenbookArch kernel: input: sof-hda-dsp Headphone as /devices/pci0000:00/0000:00:1f.3/skl_hda_dsp_generic/sound/card0/input19
lip 06 13:55:50 AsusZenbookArch kernel: input: sof-hda-dsp HDMI/DP,pcm=3 as /devices/pci0000:00/0000:00:1f.3/skl_hda_dsp_generic/sound/card0/input20
lip 06 13:55:50 AsusZenbookArch kernel: input: sof-hda-dsp HDMI/DP,pcm=4 as /devices/pci0000:00/0000:00:1f.3/skl_hda_dsp_generic/sound/card0/input21
lip 06 13:55:50 AsusZenbookArch kernel: input: sof-hda-dsp HDMI/DP,pcm=5 as /devices/pci0000:00/0000:00:1f.3/skl_hda_dsp_generic/sound/card0/input22

To clarify:

r03n commented 2 months ago

after installing the AUR package, the sound started acting strange, worked for a few seconds (still not really loud) and then extreme crackling started, even after stopping the playback and changing the profile of the speaker to OFF.

Do you use EasyEffects and Discord (or any messaging platform) by any chance? When I still had Linux installed, I had to close down these applications to not experience this issue. It is maybe caused by the fact that Pipewire and Wireplumber automatically sleeps for power save.

tholden92 commented 2 months ago

I have also started to suffer from no sound issues again. Power cycle fixes them. I do not dual boot with windows.

Might be related to newer kernel since it all worked perfectly before.

Edit: Saw someone mention fan issues. I have those, in addition to a wired CPU bug. fan will go 100% in some cases (very rare, often when I disconnect thunderbolt), and CPU will lock to 400 Mhz

matplinta commented 2 months ago

Do you use EasyEffects and Discord (or any messaging platform) by any chance?

No I do not, I have freshly installed Arch without any messaging platforms installed.

fan will go 100% in some cases (very rare, often when I disconnect thunderbolt), and CPU will lock to 400 Mhz

@tholden92 Hmm, interesting, I am on BIOS 301 and in Windows experienced this once till now, directly after disconnecting my adapter from thunderbolt port. I was sure I caught some crypto malware, since MyAsus and task manager was showing CPU 0% load and 109 C degrees temp. However I have not experienced it since...

tholden92 commented 2 months ago

@matplinta: Bios 305 here. Hopefully that can be fixed soon as well. From what I know, this is a bios issue and not OS/Linux issue.

matplinta commented 2 months ago

I guess I am kind of done with tweaking for now, at least basic functionality works both on Windows and on Linux for me. I read somewhere that kernel 6.10 release is right around the corner, I guess I will wait for it, maybe it will fix my low volume issue, since for @paul-ri it was working on mainline kernel, and the patch is scheduled upstream...

paul-ri commented 2 months ago

@matplinta

I guess rebooting from linux to linux is not the same as "cold boot"?

If I recall correctly: indeed. I had to turn off my laptop for the sound to be OK on the next boot.

Sorry about the rest of your info. This is all a very new area for me and I don't know anything about ACPI and such hardware issue. The only thing I can tell from your logs is that seeing Falling back to default firmware. is usually bad, in that it leads to low volume or something else. It was a recurring error message online with folks having similar issues.

for @paul-ri it was working on mainline kernel

Not really, I had only applied the custom patch on top of mainline kernel. Wihtout the patch, mainline was not fixing anything. Meaning we don't know if the fix is scheduled for 6.10 or later. It probably won't be 6.10 as it was already in rc6 at the time.

The kernel maintainer on the patch thread mentioned it's on their next branch. The commit is in their fork: https://github.com/tiwai/sound/commit/5f9f982dd71b418aeba7a0b37f87312545c06df4. I don't know how they usually schedule stuff! It's in the branches: master, for-next, for-linus; so sounds positive

matplinta commented 2 months ago

I guess I am kind of done with tweaking for now, at least basic functionality works both on Windows and on Linux for me. I read somewhere that kernel 6.10 release is right around the corner, I guess I will wait for it, maybe it will fix my low volume issue, since for @paul-ri it was working on mainline kernel, and the patch is scheduled upstream...

I can confirm that waiting for 6.10.1-arch1-1 and testing it did in fact remedy my situation quite a bit. I don't know if it was the kernel or the libraries that were updated alongside it. The sound is now considerably louder, without any distortions. I am not sure, however by ear it is still not the same level of loudness as on Windows, however the current state of things is acceptable for day to day tasks, movies, etc.

tholden92 commented 2 months ago

Sound works fine without this on linux-cachyos-rc kernel :)

Default firmware error message is gone, and sound is loud.

paul-ri commented 2 months ago

it is still not the same level of loudness as on Windows

@matplinta , on Windows, the "audio enhancements" option was creating a noticeable sound difference on the speakers. It's not about volume though. Disabling it would make it sound more like what was on Linux.

I wiped the laptop since then and don't notice a difference anymore, but that could be a hint for you.

waiting for 6.10.1-arch1-1 and testing it did in fact remedy my situation quite a bit

The kernel patch mentioned in this thread is not present in that version yet. Here's the list of commits for v6.10.2-arch1 for a file that should be changed by the patch: https://github.com/archlinux/linux/commits/v6.10.2-arch1/sound/pci/hda/cs35l41_hda.c

But it is present in 6.11 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/sound/pci/hda/cs35l41_hda.c?h=v6.11-rc1

EricLin0509 commented 1 month ago

I made a custom Cachyos Kernel 6.10.3 with that audio patch. But after I install it and reboot, I get no audio unless mute the audio first and then unmute it or restart wireplumber service. I got a output of systemctl:

asus-zenbook-14 wireplumber[3499]: spa.alsa: Path Capture is not a volume or mute control

How to solve this?

matplinta commented 1 month ago

@paul-ri

on Windows, the "audio enhancements" option was creating a noticeable sound difference on the speakers. It's not about volume though. Disabling it would make it sound more like what was on Linux.

Thanks, this may be the case, I will keep that in mind!

I should probably clarify, that in

waiting for 6.10.1-arch1-1 and testing it did in fact remedy my situation quite a bit

by "it" I was referring to the kernel, not the patch mentioned in this issue. Since 6.10 basically sound works fine for me, with loader volume. I wonder then what 6.11 will additionally fix for me 😅, if the mentioned patch is not merged yet.

Although I may be experiencing similar issue to @EricLin0509, because after I boot from Windows, the sound does not work unless I reset the configuration in system settings or pavucontrol (basically set the speakers to off, then to "Play HiFi quality music")