Bug 218991

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