Samsung Galaxy Book4 Pro 360 (NP960QGK) - No sound from internal speakers (ALC298/MAX98390)

[stephanlensky]

Bug Bounty

I have pledged a $500 USD bug bounty for fixing this issue. Additional details here.

Additional pledgers welcome, please submit a PR to my repository if you are interested in contributing.

System Information

• Laptop model: Galaxy Book4 Pro 360 (NP960QGK)
• Kernel version: 6.17.8-arch1-1
• Distribution: EndeavourOS (Arch Linux)
• Audio controller: Intel Corporation Meteor Lake-P HD Audio Controller [8086:7e28] (rev 20)
• HDA codec: Realtek ALC298 (Subsystem ID: 0x144dc892)
• Speaker amplifiers: 4x Maxim MAX98390

Current status

The internal speakers are not working.

• Headphone jack is working, but not the internal speakers.
• This issue is similar to previous Samsung Galaxy Book models, which required HDA verb speaker amplifier quirks.
• However, unlike previous models, we have not yet been able to hear output from the speakers while running Windows in QEMU with official drivers. This model may require additional initialization of the MAX98390 amplifiers over I2C.
  • I was working on dumping the HDA verbs through QEMU, but since I wasn't able to hear any audio I wasn't sure if it would be helpful.
  • More of my notes about running Windows in QEMU can be found here.

Related issues

Kernel Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=220808

Similar variants

This issue is closely related to the following issues for the Galaxy Book4 Pro (NP940XGK)

• Samsung Galaxy Book4 Pro 14" (NP940XGK) - speakers do not work #5002
• Samsung Galaxy Book 4 Pro (940XGK) - No speaker audio, MAX98390 amplifiers not integrated #5568
• Kernel Bugzilla #218862 [Samsung Galaxy Book4 Pro - 940XGK] No sound from internal speakers

But I am creating a separate issue to track the fix for this specific laptop variant.

Additional details

I have provided a bunch of additional details and logs in my repository stephanlensky/galaxy-book4-linux-sound.

• acpidump.log - Output of acpidump
• alsa-info.txt - Output of alsa-info.sh
• build.config - Contents of /usr/lib/modules/$(uname -r)/build/.config
• dmesg.log - Output of dmesg directly after boot
• lspci.txt - Output of lspci -knn

Testing

I am happy to help with any required testing for fixing this, please just let me know what to do.

[joshuagrisham]

Hi @stephanlensky I saw all of your posts here and there and decided to reply here now 😎

I think it is going to be really hard to try to figure this out without full dump data from sound actually working from the speakers. So I think step 1 will be if you can get a QEMU guest running Windows plus all of the necessary devices forwarded, the drivers installed in the guest OS, and sound actually coming out of the speakers.... PLUS that you can generate debug output that shows all of the verbs that are being sent.

I described basically what I would want in order to have any shot at looking at this here: #4055 (comment)

In that post I also mention a patch I made to QEMU's vfio-common which adds timestamps to each line in the log that GREATLY help in figuring this out (IMO).

So my direction would be, see if you can get the Windows guest in QEMU working with the devices forwarded, drivers installed, actual sound coming from the speakers, and then see if you can generate a debug output using a patched QEMU which gives the verbs with timestamps, and then I would hope that we can probably figure out how to get this working from there 🙂

[stephanlensky]

Thank you @joshuagrisham! Sorry for the spam everywhere, doing my best contribute but unfortunately I am fairly new to this still so it may not be very helpful 😅

I've been following your posts as well and also read through your process for fixing the Book2/Book3. I agree, getting the verb output would be a great first step.

I actually tried this already with an unpatched QEMU just to see if I could hear anything, but unfortunately even with the devices passed through and driver seemingly installed there was no speaker output (and actually, the drivers seemed to show some errors in the device manager). I may have overcomplicated things by trying to use the original Samsung Windows install which shipped with the laptop, I will give it another try and see if I can get things working with a clean install and just the Samsung audio driver.

My original messy notes are here in case anything jumps out at you as obviously incorrect with my process of passing through the devices, but please don't spend too long looking at it until I attempt it a second time.

[joshuagrisham]

Hi @stephanlensky not to worry at all 🙂
The one thing I noticed was regarding what to actually install and where to get it.. before there was a program in Windows called "Samsung Update" which downloaded drivers and installed them but IIRC they have moved away from this tool and are using something like "Samsung Device Care" in Windows now?

Anyway the problem with trying to use that tool was that it actually had a dependency on the ACPI device (the same that the samsung-galaxybook driver uses) and a few other EC devices so I never really got it working to forward all of them to my QEMU guest. Instead what I did was to use the Samsung Update tool in Windows to just download the driver package (without installing it) and then I mounted a volume to the VM with these so I could just directly install the specific driver packages.

Maybe you have already figured this out but if not hopefully it is a good tip for you to look into!

Also I am not sure if the new Samsung Device Care has a button to just download, but worst case you can use something like Wireshark or other sniffing tool in Windows to capture the URL it is fetching the driver from, or if it still works similarly there was an XML file with all of the drivers and their download URLs you can look for instead