7

I just bought an ASUS Zenbook 14, model UX3402 (Q409Z when purchased from Best Buy in the US). It came with Windows 11 installed, and sound output works perfectly on Windows. I installed Ubuntu 22.04 on it, and everything works except for the internal speakers. It uses the Realtek ALC294 codec, and shows both Harman/Kardon and Dolby Atmos logos on the keyboard deck. I've tried all the suggestions, like using hdajackretask to enable and route various pins, forcing the snd_hda_intel kernel module (snd_sof_intel_hda was the default), reinstalling alsa and pulseaudio, disabling fastboot in the BIOS but nothing works. Not one peep out of the internal speakers. I also tried messing with the GPIO assignments using hda-verb, but no luck.

The funny thing is, the headphone jack and audio out from both HDMI and Thunderbolt/DisplayPort works. I can plug in headphones and hear sound without any issue. So clearly the sound hardware is supported. I think the problem may be with this particular laptop's sound system. It uses a surround-style audio setup, with possibly 4 speakers. It may also be using a built-in amplifier that is not getting enabled. When Windows was installed, the Device Manager showed a "Cirrus Logic Awesome Speaker Amps" device under "Sound, video and game controllers":

enter image description here

However, I didn't see anything about this when running lspci under Ubuntu.

Here's the output from dmesg when the sound driver loads:

[    3.628292] snd_hda_intel 0000:00:1f.3: enabling device (0000 -> 0002)
[    3.628620] snd_hda_intel 0000:00:1f.3: Applying patch firmware 'hda-jack-retask.fw'
[    4.956625] snd_hda_intel 0000:00:1f.3: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915])
[    5.052007] snd_hda_codec_realtek hdaudioC0D0: autoconfig for ALC294: line_outs=1 (0x17/0x0/0x0/0x0/0x0) type:speaker
[    5.052013] snd_hda_codec_realtek hdaudioC0D0:    speaker_outs=0 (0x0/0x0/0x0/0x0/0x0)
[    5.052016] snd_hda_codec_realtek hdaudioC0D0:    hp_outs=1 (0x21/0x0/0x0/0x0/0x0)
[    5.052017] snd_hda_codec_realtek hdaudioC0D0:    mono: mono_out=0x0
[    5.052018] snd_hda_codec_realtek hdaudioC0D0:    inputs:
[    5.052019] snd_hda_codec_realtek hdaudioC0D0:      Headset Mic=0x19

Has anyone encountered this problem with a laptop using a built-in amplifier?

UPDATE 1:

I believe the laptop's speakers rely on a Cirrus Logic CS35L41 amplifier IC connected over the SPI bus. Unfortunately, I don't think there is a Linux driver, so no way to enable it and send commands to it. A driver is apparently being worked on by a Cirrus Logic employee, but there's no telling if/when it will be completed and if it will be compatible with this laptop:

enter image description here

UPDATE 2:

I installed kernel 5.18.0rc7, and got the following output from dmesg:

[    1.718769] platform CSC3551:00: hash matches
[    1.718805] acpi CSC3551:00: hash matches
[    2.896282] Serial bus multi instantiate pseudo device driver CSC3551:00: Instantiated 2 SPI devices.
[    2.989842] cs35l41_hda: probe of spi1-CSC3551:00-cs35l41-hda.0 failed with error -22
[    2.990220] cs35l41_hda: probe of spi1-CSC3551:00-cs35l41-hda.1 failed with error -22

Looks like the kernel is detecting the amps on the SPI bus, but cannot get past the probing due to the -22 error. So, seems like things are getting closer, but not quite there yet.

UPDATE 3:

I opened the laptop, and I see two CS35L51X chips side by side on the motherboard. So this laptop uses two CS35L51 amplifiers, not CS35L41. Not sure if this matters, but it's definitely a different (newer?) chip.

UPDATE 4:

Tried with kernel 5.19.0rc4. Still not working, although there is an additional "platform not supported" message. I guess this is what error -22 means:

[    4.807553] Serial bus multi instantiate pseudo device driver CSC3551:00: Instantiated 2 SPI devices.
[    5.053785] cs35l41-hda spi1-CSC3551:00-cs35l41-hda.0: error -EINVAL: Platform not supported -22
[    5.053791] cs35l41-hda: probe of spi1-CSC3551:00-cs35l41-hda.0 failed with error -22
[    5.054477] cs35l41-hda spi1-CSC3551:00-cs35l41-hda.1: error -EINVAL: Platform not supported -22
[    5.054487] cs35l41-hda: probe of spi1-CSC3551:00-cs35l41-hda.1 failed with error -22

UPDATE 5:

Tried with kernel 6.0 RC3. I am getting the same results described by Bo Gao below (missing ACPI _DSD properties). Here is the dmesg output:

[    4.245350] Serial bus multi instantiate pseudo device driver CSC3551:00: Instantiated 2 SPI devices.
[    4.674892] cs35l41-hda spi1-CSC3551:00-cs35l41-hda.0: Error: ACPI _DSD Properties are missing for HID CSC3551.
[    4.674953] cs35l41-hda spi1-CSC3551:00-cs35l41-hda.0: error -EINVAL: Platform not supported
[    4.675000] cs35l41-hda: probe of spi1-CSC3551:00-cs35l41-hda.0 failed with error -22
[    4.675363] cs35l41-hda spi1-CSC3551:00-cs35l41-hda.1: Error: ACPI _DSD Properties are missing for HID CSC3551.
[    4.675413] cs35l41-hda spi1-CSC3551:00-cs35l41-hda.1: error -EINVAL: Platform not supported
[    4.675454] cs35l41-hda: probe of spi1-CSC3551:00-cs35l41-hda.1 failed with error -22

Despite these properties missing from the BIOS, these amplifiers still work perfectly on Windows. So perhaps these properties can be recovered from a Windows install. I have dual Linux/Windows boot on this laptop, so it's easy for me to look for anything needed by the the Cirrus Logic open source people (if you're listening, let me know!).

UPDATE 6:

I tried compiling a 5.19 kernel using (modified) patches referenced by Bo Gao. At least one amp appeared to activate OK, but still no sound and rebooting did not help. However, my setup is different. The PCI quirks patch posted might not work with this laptop, as the amps are connected over SPI, not I2C and the patch referenced seems to be for I2C. Also, this laptop uses the Realtek ALC294 codec. Here is the dmesg output:

[    4.272896] cs35l41-hda spi1-CSC3551:00-cs35l41-hda.0: Cirrus Logic CS35L41 (35a40), Revision: B2
[    4.273073] cs35l41-hda spi1-CSC3551:00-cs35l41-hda.1: Reset line busy, assuming shared reset
[    4.377887] cs35l41-hda spi1-CSC3551:00-cs35l41-hda.1: Failed waiting for OTP_BOOT_DONE: -110
[    4.377984] cs35l41-hda: probe of spi1-CSC3551:00-cs35l41-hda.1 failed with error -110

I tried a few variations of the PCI quirks in the Realtek patch (the ones prefixed with "ALC294"), but none worked. I'm not sure these quirks are actually being selected. Is there any way to verify they're active?

Improve this question
3
  • 1
    Just because the audio device works sometimes (on headphones) doesn't mean that it is supported or that you are using the correct driver. Maybe you have partial support. Also possibly, maybe you need to select a different device to get it to work.
    – user10489
    May 7, 2022 at 22:42
  • Finally, I got the sound working on my UX3402 (with SPI, not I2C), by patching the missing ACPI properties. The details are here: gist.github.com/lamperez/862763881c0e1c812392b5574727f6ff (I do not have reputation to post an answer).
    – krollspell
    Mar 27, 2023 at 12:13
  • @krollspell Thanks. I wish I would have seen this before changing laptops. I replaced the ASUS with a Lenovo Yoga 9i that worked with Ubuntu right out of the box, even with its fancy sound setup.
    – Synthetix
    Mar 27, 2023 at 12:29

5 Answers 5

Reset to default
4

I don't have the reputation to comment on Frithjof's post, so here are the changes I needed to get audio working on my UM3402YA. I'm using a current Arch Linux installation.

  1. Downloaded and installed linux kernel 6.1-rc6 from www.kernel.org

Current Arch kernel is newer -> I skipped this step.

  1. Installed firmware (debian: firmware-amd-graphics.deb) and Cirrus firmware: https://github.com/CirrusLogic/linux-firmware/tree/main/cirrus

Currently, the firmware for my device (1043:1e12) is not merged. Get the firmware from the open pull request.

  1. Applied this patch (may not be necessary): https://www.spinics.net/lists/platform-driver-x86/msg35828.html

I applied it.

  1. Added the following lines to file linux/sound/pci/hda/cs35l42.c, line 1237:
 } else if (strncmp(hid, "CSC3551", 7) == 0) {
     hw_cfg->bst_type = CS35L41_INT_BOOST;
     hw_cfg->gpio1.func = CS35l41_VSPK_SWITCH;
     hw_cfg->gpio1.valid = true;
 } else {

I patched the file cs35l41_hda.c(not cs35l42.c). After that I still got Error in Boost DT config messages and no sound. I played around and found a working setting for me: hw_cfg->bst_type = CS35L41_EXT_BOOST;

  1. Built kernel, reboot. You should see the driver load in /var/log/syslog:

Works for me:

[   11.501963] Serial bus multi instantiate pseudo device driver CSC3551:00: Instantiated 2 I2C devices.
[   11.894332] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.0: Cirrus Logic CS35L41 (35a40), Revision: B2
[   11.895040] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.1: Reset line busy, assuming shared reset
[   11.928297] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.1: Cirrus Logic CS35L41 (35a40), Revision: B2
[   12.991402] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.0: DSP1: Firmware version: 3
[   12.991405] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.0: DSP1: cirrus/cs35l41-dsp1-spk-prot-10431e12.wmfw: Fri 27 Aug 2021 14:58:19 W. Europe Daylight Time
[   13.486872] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.0: DSP1: Firmware: 400a4 vendor: 0x2 v0.43.1, 2 algorithms
[   13.488019] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.0: DSP1: 0: ID cd v29.63.1 XM@94 YM@e
[   13.488022] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.0: DSP1: 1: ID f20b v0.1.0 XM@176 YM@0
[   13.488025] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.0: DSP1: spk-prot: C:\Users\tyang\Desktop\Product Setting\SmartAMP\ASUS\ASUS_Zenbook\UM3402\Tuning_Release\220304\ASUS_UM3402_L_tuning_IDYC_ReDC_Finish_PICL_RTL_0304.bin
[   13.588115] snd_hda_codec_realtek hdaudioC1D0: bound i2c-CSC3551:00-cs35l41-hda.0 (ops cs35l41_hda_comp_ops [snd_hda_scodec_cs35l41])
[   13.591407] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.1: DSP1: Firmware version: 3
[   13.591409] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.1: DSP1: cirrus/cs35l41-dsp1-spk-prot-10431e12.wmfw: Fri 27 Aug 2021 14:58:19 W. Europe Daylight Time
[   14.087987] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.1: DSP1: Firmware: 400a4 vendor: 0x2 v0.43.1, 2 algorithms
[   14.089170] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.1: DSP1: 0: ID cd v29.63.1 XM@94 YM@e
[   14.089175] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.1: DSP1: 1: ID f20b v0.1.0 XM@176 YM@0
[   14.089181] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.1: DSP1: spk-prot: C:\Users\tyang\Desktop\Product Setting\SmartAMP\ASUS\ASUS_Zenbook\UM3402\Tuning_Release\220304\ASUS_UM3402_R_tuning_IDYC_ReDC_Finish_PICL_RTL_0304.bin
[   14.191727] snd_hda_codec_realtek hdaudioC1D0: bound i2c-CSC3551:00-cs35l41-hda.1 (ops cs35l41_hda_comp_ops [snd_hda_scodec_cs35l41])
  1. Still no sound. Made a half-educated guess about a quirk. Add the following line to file linux/sound/pci/hda/patch_realtek.c, line 9406:

Yes.

  1. Test sound via loudspeakers.

It works :)

Improve this answer
3
  • 1
    This worked for me on Linux 6.2.2 on Ubuntu's mainline kernel on the UM3402YA! However, upon booting, I occasionally saw a BUG: kernel NULL pointer dereference upon boot with a call trace containing comp_generic_playback_hook+0x3b/0x60. It seems that trying to access the audio device while the device is still initialising might be the issue. In that function, which is in sound/pci/hda/patch_realtek.c, updating the if block to say if (spec->comps[i].dev && spec->comps[i].playback_hook) makes it work perfectly. Audio sounds softer than in Windows, but hey, at least it works.
    – Yong Jie Wong
    Mar 5, 2023 at 16:14
  • Hello, can anyone please upload working kernel for UM3402YA. I created this thread and no luck so far: forum.manjaro.org/t/no-sound-on-asus-zenbook-um3402ya/136786/11
    – Sharmiko
    Mar 24, 2023 at 9:51
  • Update on UM3402YA: I have since upgraded to Linux 6.3.7, kernel patches are no longer required. Patching the DSDT/SSDT alone allows sound to work, pretty much indistinguishable from Windows. The DSDT patch is available at: gist.github.com/masselstine/8fe9634b4c31cef07b8dfab089e4eb38
    – Yong Jie Wong
    Jun 17, 2023 at 17:59
4

I got sound via loud speakers to work on my Asus Zenbook UM3402YA. Here are the steps:

  1. Downloaded and installed linux kernel 6.1-rc6 from www.kernel.org

  2. Installed firmware (debian: firmware-amd-graphics.deb) and Cirrus firmware: https://github.com/CirrusLogic/linux-firmware/tree/main/cirrus

  3. Applied this patch (may not be necessary): https://www.spinics.net/lists/platform-driver-x86/msg35828.html

  4. Added the following lines to file linux/sound/pci/hda/cs35l42.c, line 1237:

     } else if (strncmp(hid, "CSC3551", 7) == 0) {
     hw_cfg->bst_type = CS35L41_INT_BOOST;
     hw_cfg->gpio1.func = CS35l41_VSPK_SWITCH;
     hw_cfg->gpio1.valid = true;
 } else {

  5. Built kernel, reboot. You should see the driver load in /var/log/syslog:

     debian kernel: [8.049401] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.0: Cirrus Logic CS35L41 (35a40), Revision: B2
 debian kernel: [8.049544] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.1: Reset line busy, assuming shared reset
 debian kernel: [8.083870] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.1: Cirrus Logic CS35L41 (35a40), Revision: B2

  6. Still no sound. Made a half-educated guess about a quirk. Add the following line to file linux/sound/pci/hda/patch_realtek.c, line 9406:

     SND_PCI_QUIRK(0x1043, 0x1e12, "ASUS UM3402", ALC287_FIXUP_CS35L41_I2C_2),

    Built kernel, reboot. You should find that firmware was loaded:

     debian kernel: [8.582376] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.0: DSP1: Firmware version: 3
 debian kernel: [8.582382] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.0: DSP1: cirrus/cs35l41-dsp1-spk-prot.wmfw: Fri 24 Ju

  7. Test sound via loudspeakers.

Update: I promised to check again with the new LTS kernel 6.1.4. Patches described in steps 4 and 6 are still necessary. No idea whether CS35L41_INT_BOOST or CS35L41_EXT_BOOST is correct (both work). Make sure that you have firmware file cs35l41-dsp1-spk-prot.wmfw installed in /lib/firmware/cirrus.

Improve this answer
3
  • 1
    Wow, great sleuthing! Have you contacted the maintainers for linux/sound/pci/hda/patch_realtek.c and linux/sound/pci/hda/cs35l42.c about importing your patches? If you do a PR then be sure to add Cc: [email protected] in your commit message because, at least IMHO, this meets linux stable rules
    – KJ7LNW
    Jan 22, 2023 at 6:34
  • 1
    Thanks for your kind words. I did so. They said that I should wait for them to release their drivers and not risk damaging my laptop. I do not think that my four additional lines pose any risk. I still enjoy my laptop.
    – Frithjof Kruggel
    Jan 24, 2023 at 3:26
  • Ya, thats CYA on their part if they work for the chipset/hardware manufacturer. Hopefully they will take a look at your changes and at least use it as informed direction to add support!
    – KJ7LNW
    Jan 24, 2023 at 20:32
2

I'm in the exact same predicament with my UX3402. I was in the weeds trying to debug the ALC294 codec when your discovery of the cirrus chip helped get me on the right track.

I think I've uncovered slightly more about the issue with the cirrus chip. AFAICT, our devices have two cs35l41's connected over SPI interfaces. We also have a node in the ACPI table called CSC3551, which tells the OS where to find the two csc35l41's. I think this patch series from January is adding support for the CSC3551 ACPI node. The patch made it into a release for the first time in 5.18-rc1.

So, I made upgraded to 5.18-rc7 (which also has the patch), and... no good. Now, I'm getting a new error in dmesg. [ 1.393985] Serial bus multi instantiate pseudo device driver CSC3551:00: error -ENODEV: failed to allocate SPI device CSC3551:00 from ACPI: -19

I've got no idea what this means. I tried to do some debugging but didn't get very far. So, I submitted a bug in the Linux Bugzilla here

PostScript: I highly recommend upgrading your kernel to at least 5.17. I saw noticeably better, battery life. And even better on 5.18. Manjaro makes switching between kernels very easy

Improve this answer
3
  • Thanks. I did try 5.18, and also compiled my own kernel from source to ensure I got the latest fixes, but no difference. However, I didn't check the kernel output like you did, which may contain hints. I'll try recompiling again and see if anything has changed. I'll report back what I find!
    – Synthetix
    May 19, 2022 at 1:15
  • Interesting that you got different error messages than me on the same system. Any chance you could upload your kernel config? Here's mine drive.google.com/file/d/1URLPBmXtlcRbRwScVa3QBLd1IImB6v_t/…
    – Matthew Perlick
    May 25, 2022 at 19:23
  • Regarding those errors, I was using the 5.18rc7 Ubuntu vanilla kernel build, available here: kernel.ubuntu.com/~kernel-ppa/mainline/v5.18-rc7 You can probably pull the kernel config file out of one of those .deb packages and use it to compile your own. Or I guess you can just install it on your distro somehow if you can work with Debian packages. Updated: here's the config: pastebin.com/bvKAyWu5
    – Synthetix
    May 25, 2022 at 19:54
2

Same here, running 6.0-rc1 with config file pulled from Canonical's 5.19 mainline deb packages. With the latest patch I added manually from kernel patchwork, I was able to pinpoint where the problem is: this laptop does not have a BIOS which properly describes how the amplifier should be set up.

The amplifier is a smart one, and needs some parameters on speaker, passive components and more to fine tune the algorithm inside, and the BIOS was supposed to supply a _DSD property in its ACPI table's CSC3551 section, which is does not. So the driver got confused and does not know how to configure the chip.

I tried (don't do this, this can burn your chip) to force the driver to load the default parameters and bypass _DSD parameter acquisition, then it throws unable boot error to me, it says the OTP ROM boot took too long. At this point, I have no idea what to do, and I think the best course of action is to wait.

FYI, my device is Zenbook S 13 OLED, the CS35L41 chips are connected over I2C.

Improve this answer
3
  • 1
    Do you think it would be possible to figure out what the properties should be from a working Windows install?
    – Synthetix
    Sep 5, 2022 at 18:33
  • 1
    Turns your you just have to reboot it. Set the device to default parameter and force it to load, it won't work on this boot, but on the next boot it works fine. Check our Arch AUR, they have a UM5302TA linux package, which does exactly this. You also need to add a Realtek quirk, which is also included in that repo. aur.archlinux.org/packages/linux-mainline-um5302ta
    – Bo Gao
    Sep 6, 2022 at 3:58
  • 1
    Nice one, great news! I don't have a UM5302TA, so I'm afraid the PCI quirk won't work on my laptop. I can create a new entry in that patch with my model so it picks up my laptop. Do I just need to add my device with the appropriate PCI identifier? I ran lspci -vv and found this line: Multimedia audio controller: Intel Corporation Alder Lake PCH-P High Definition Audio Controller (rev 01) DeviceName: Onboard - Sound Subsystem: ASUSTeK Computer Inc. Device 1e02. So would I create a quirk with"0x1043, 0x1e02" ?
    – Synthetix
    Sep 6, 2022 at 20:47
1

Please check solution (SSDT patch) described here: https://gist.github.com/lamperez/862763881c0e1c812392b5574727f6ff?permalink_comment_id=4531290#gistcomment-4531290

Working with 6.3.7 kernel.

Improve this answer
1

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .