Created attachment 306500 [details] Output of 'sudo dmesg > dmesg.log' Hi, Details: * Laptop name: ASUS Zenbook 14 UX3405MA * PCI_SUBSYS_ID: 1043:1A63 * BIOS: 305 03/05/2024 * OS: Arch Linux 6.9.6-arch1-1 * Amplifier chip (according to dmesg): Cirrus Logic CS35L41 (35a40), Revision: B2 The maximum volume on this laptop is perceptively around 1/4th of what Windows can reach. Building a linux-mainline kernel (6.10.0-rc3) with a (hacky) patch restores full volume. I have attached the "zenbook.patch" file. Source: the gist linked in this comment [1]. As the author mentions, this is just a functional hack that could help someone familiar with the issue identify what's a fault and write a better fix. Looking at other similar bugs & patches, it looks like patch_realtek.c would need modified too? It makes no reference to the 'UX3405MA' model. Further details: * The output of `udevadm info /sys/bus/pci/devices/0000:00:00.0 | grep PCI_SUBSYS_ID` is `E: PCI_SUBSYS_ID=1043:1A63` * Other folks are providing an SSDT file to patch the system volume successfully too [2] * They also provide some Wireplumber config files that fix recurring crackling noises on that laptop when using either of the high-volume solutions. I don't know if this is related to the bug. I will attach an acpi dump too. Thanks! [1]: https://gist.github.com/lamperez/862763881c0e1c812392b5574727f6ff?permalink_comment_id=5010590#gistcomment-5010590 [2]: https://github.com/smallcms/asus_zenbook_ux3405ma/blob/main/ssdt-csc3551.dsl
Created attachment 306501 [details] Output of 'sudo acpidump > acpi.dat'
Created attachment 306502 [details] cs35l41_hda_property.c hack restoring full volume Source: https://gist.github.com/steffengy/aa48549f40c37acf85de7a7f9a6c0475 Description from the author: https://gist.github.com/lamperez/862763881c0e1c812392b5574727f6ff?permalink_comment_id=5010590#gistcomment-5010590
addendum: patch_realtek.c does already refer to the "ASUS UX3405MA". It was done in this commit: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/sound/pci/hda/patch_realtek.c?h=v6.10-rc5&id=61cbc08fdb04fd445458b0f4cba7e6929afdfaef That leaves likely only cs35l41_hda_property.c to be updated. I forgot to mention also that I had to install the 'sof-firmware' (Sound Open Firmware) package, otherwise no sound card would be recognised.
Created attachment 306519 [details] Proposed fix Hi, I have a potential fix for this issue. Please see the attached, and if possible, test it and let me know if it fixes the issue for you. Thanks, Stefan
Thanks for the file Stefan. I have attached a new dmesg log file of a fresh boot into linux-mainline 6.10.0rc6 with your patch applied, no acpi_override file, and started a tune shortly after opening a desktop session. The log highlights a speaker issue described below, but this may be unrelated to the volume issue. ## The good Volume is loud, to the expected level. That part is fixed. Amazing! ## The bad Some same problems that existed before persist, or I have slightly more details for others. They likely are unrelated to the volume issue; so I will understand if this is not in the scope of this bug report. These were tried on VLC and Spotify. * Crackling audio glitches still happen. Rarely though. Looks like I still need the config files provided in here: [1]. * The left, right or both speakers will randomly not produce any sound after boot or restarting pipewire & wireplumber. This also happens on the non-patched kernel. The error printed on dmesg (here when both speakers don't produce sound) > cs35l41-hda spi1-CSC3551:00-cs35l41-hda.0: Failed waiting for CS35L41_PUP_DONE_MASK: -110 > cs35l41-hda spi1-CSC3551:00-cs35l41-hda.1: Failed waiting for CS35L41_PUP_DONE_MASK: -110 * When one of the speakers fail to produce sound, the other sometimes gets distorted. These were only reproducible on VLC: * It sometimes plays at ~1/2 a tone down, sometimes changing whilst the tune plays (that's a lot of 'sometimes', but it's that random) * I can sometimes hear an echo of <1s. It's hard to replicate these issues as they are sporadic. ~50-70% of the time, things are fine. Or I restart wireplumber / pipewire until it works. This was only after a bit of an afternoon testing. Thanks again. It is up to you to decide if these errors are unrelated to the volume issue and need their own bug report elsewhere. The volume being fixed here is a great plus already : ) [1]: https://github.com/smallcms/asus_zenbook_ux3405ma/tree/main/fix_pop_crack_pop
Created attachment 306521 [details] dmesg with patch#2 and tune played 'Failed waiting for CS35L41_PUP_DONE_MASK' displayed at the end of the log, both speakers fail to produce sound. Restarting pipewire / wireplumber fixed this.
Hi, Thanks for testing that patch. The audio glitches due to Pipewire/Wireplumber are out of scope for this ticket, and doesn't seem related to the driver. However, the issue with the 'Failed waiting for CS35L41_PUP_DONE_MASK' message is an unusual failure. Can you tell me when you started having this issue? I notice that you updated your kernel to 6.10-rc6 in between the bug report and trying the fix, did you ever see this issue on the older kernel, or with the fixes you used previously? Do you see this issue when you used no fix - i.e. when using it with low volume? It looks like the firmware and tuning for that laptop are now out of date, and I've pushed up the latest tuning for that laptop (though it may take some time for it to be accepted). Can you try testing with the latest firmware too? The patch for that is available here: https://github.com/CirrusLogic/linux-firmware/commit/fe07c4bdd435c623fdf215bb0d94f9e6f838e164 Please let me know if you still get that error message. Thanks, Stefan
Created attachment 306524 [details] dmesg on linux 6.9.7 with suggested path and 2024-07-02 cirrus firmware after booting from Windows ## Answers > Can you tell me when you started having this issue? Since I have the laptop. But always randomly. One of the 2 speakers would be off. > did you ever see this issue on the older kernel, or with the fixes you used > previously? yes & yes > Can you try testing with the latest firmware too? Done, same problem. I also used stable-linux (6.9.7) instead of linux-mainline (6.10, which I was using in case something newer would fix issues). I tweaked Arch Linux's recipe for their linux-firmware package to include your new files. I don't notice anything different by ear. ## Reproducing the issue Turns out I can reproduce the issue consistently (3 or 4 attempts) of seeing CS35L41_PUP_DONE_MASK on the system logs with speaker(s) not producing sounds by... restarting to Linux from Windows! I have setup a dual boot with Windows. And the 'sporadic' manner in which I was seeing issues must have been coming from the fact I would have sometimes rebooted from Windows or done a cold start. No matter how many times I restart to Linux after having gone once from Windows, the speaker(s) would fail until I restart pipewire & wireplumber in the session. A cold start to Linux starts with no problem, and appears to be fine. Apologies for such a niche issue. I'm glad to have found this behaviour quickly enough as I could have searched for a long time what was causing this. But I didn't have that many variables to play with. ## Files I have attached 1 system log after having rebooted from Windows, showing CS35L41_PUP_DONE_MASK towards the end. Another will be uploaded, after a cold boot to Linux, which does not show errors
Created attachment 306525 [details] dmesg on linux 6.9.7 with suggested path and 2024-07-02 cirrus firmware from a cold start Attached system logs from a cold start to 6.9.7 with the kernel patch and with the linux-firmware updates from the Cirrus repo's '2024-07-02' branch. Audio there is fine. I would consider this issue fixed, if we choose to ignore the 'CS35L41_PUP_DONE_MASK' problems when restarting to Linux from Windows. Which I am hoping is the definite explanation despite my limited attempts.
Hi, I'm not sure why there is a difference between booting from Windows into Linux, but I think Dual-booting can sometimes have strange behaviours. I notice in your logs that systemd seems to be killed and reset part way through for some reason, which might be due to dual booting. Also, I saw from the logs that Linux is using Modern Standby, which means that Windows will be to. As far as I know Modern Standby changes the way "shutdown" works, and it may not power down the system completely, though I believe "restart" or "reboot" will do a power cycle. I think Modern Standby might also affect what the BIOS does after a shutdown or reboot too. I don't know how that affects things when switching OS' - if the Modern Standby has prevented a power cycle, or affected the BIOS. Such a thing could affect the hardware in weird ways and could cause the error you are seeing. In this case, I think its unlikely the driver is to blame for this issue. I will send the fix upstream. Thanks, Stefan
Many thanks Stefan. I have marked the bug as "RESOLVED -> CODE_FIX", hopefully that's correct. I appreciate the boot insights. I have mostly chosen the vanilla or recommended settings when setting up dual boot, but been recently trying to finally use hibernation and its various options. I'll explore these caveats eventually, fun! Your fix will make a few owners happy. Thanks again, Paul