[BUG] Samsung Galaxy Book2 Pro 360 no sound through speaker

[datmischa]

Describe the bug
On my Galaxy Book2 Pro 360, there is no audio output through the internal speakers. Audio works fine with headphones (wired as well as bluetooth), could not test over usbc - displayport cable yet, but guessing this works too. If I play some test sound through speaker-test, I can see the indicator in the plasma-pa applet moving.
I tested the internal microphone with arecord, it works as well.

What have you tried to diagnose or workaround this issue?
Installed mainline kernel (5.19-rc5) and sof-firmware 2.2 with no effect.

To Reproduce
Installed / booted various Linux derivates (Gentoo, Arch, Void, Ubuntu, Fedora) with the same outcome.

Reproduction Rate
100% of the time.

Expected behavior
Sound is playing through internal speakers

Impact
deal breaker, no sound on the go

Environment

1. Branch name and commit hash of the 2 repositories: sof (firmware/topology) and linux (kernel driver).

   • Kernel: (5.18.9) https://archlinux.org/packages/core/x86_64/linux/files/
   • SOF: (2.1.1) https://archlinux.org/packages/extra/x86_64/sof-firmware/

2. Name of the topology file:
   Topology: ABI 3:22:1 Kernel ABI 3:21:0 (dmesg output)

3. Name of the platform(s) on which the bug is observed.

   • Platform: ARCH (and derivates), Gentoo, Fedora, Ubuntu

dmesg
dmesg_grep_sof.txt
dmesg.txt

sof-logger
freezes my system

alsa-info.txt

[plbossart]

This is likely a codec and amplifier issue, see suggestions to double-check if this also happens with the legacy HDaudio driver.

https://thesofproject.github.io/latest/getting_started/intel_debug/suggestions.html#disable-sof-on-pci-hdaudio-devices-to-test-audio-playback

[datmischa]

I finally got my speakers working.

Steps to reproduce
/etc/pulse/default.pa
#load-module module-suspend-on-idle
and run the script (credits to drlucas from manjaro.org)
https://pastebin.com/raw/zsXp2vz6

I have to rerun the script every time I restart/wake the PC from sleep.
What would be the appropriate place to get this script implemented into the kernel/driver/firmware, so that this hack does not have to be used?

[lgirdwood]

@datmischa thanks for posting the script, GH has mangled the URL but it works if copy and pasted.

I've pasted the top of the script below and it looks like its the same verbs being modified over and over. Are you able to reduce this script to a minimum set of verb writes ? Once the minimum verbs are known it should be possible to patch the drivers.

#!/bin/bash

sudo hda-verb /dev/snd/hwC0D0 0x1a SET_PIN_WIDGET_CONTROL 0x5
sudo hda-verb /dev/snd/hwC0D0 0x20 0x500 0x2b
sudo hda-verb /dev/snd/hwC0D0 0x20 0xc00 0x0
sudo hda-verb /dev/snd/hwC0D0 0x20 0x500 0x2b
sudo hda-verb /dev/snd/hwC0D0 0x20 0x40c 0x10
sudo hda-verb /dev/snd/hwC0D0 0x20 0x500 0x3
sudo hda-verb /dev/snd/hwC0D0 0x20 0x400 0x42
sudo hda-verb /dev/snd/hwC0D0 0x20 0x500 0x5
sudo hda-verb /dev/snd/hwC0D0 0x20 0x42b 0xe0
sudo hda-verb /dev/snd/hwC0D0 0x20 0x500 0x8
sudo hda-verb /dev/snd/hwC0D0 0x20 0x42f 0xcf
sudo hda-verb /dev/snd/hwC0D0 0x20 0x500 0xe
sudo hda-verb /dev/snd/hwC0D0 0x20 0x46f 0x80
sudo hda-verb /dev/snd/hwC0D0 0x20 0x500 0xf
sudo hda-verb /dev/snd/hwC0D0 0x20 0x400 0x62
sudo hda-verb /dev/snd/hwC0D0 0x20 0x500 0x10
sudo hda-verb /dev/snd/hwC0D0 0x20 0x40e 0x21
sudo hda-verb /dev/snd/hwC0D0 0x20 0x500 0x11
sudo hda-verb /dev/snd/hwC0D0 0x20 0x500 0x19
sudo hda-verb /dev/snd/hwC0D0 0x20 0x400 0x17
sudo hda-verb /dev/snd/hwC0D0 0x20 0x500 0x2b
sudo hda-verb /dev/snd/hwC0D0 0x20 0x40c 0x10

Fwiw verb 0x500 looks like it could be a volume ramp (and maybe some others could be too).

[F0xedb]

Hi @lgirdwood,

I'm able to replicate the verbs working on the Galaxy Book 2 Pro 360.

Since the original Author is not replying I might be able to assist with getting the minimal verb list to get it working.
What is the best approach to get this minimum set of verbs?

[lgirdwood]

@F0xedb I think you have to use this tool to dump the needed verbs https://github.com/Conmanx360/QemuHDADump, once known they can then be upstreamed to the Linux codec driver.
@plbossart @ujfalusi @bardliao please correct me if I'm wrong.

This issue seems to affect other Galaxy Book Models too

[joshuagrisham]

Hi!

I have the Galaxy Book2 Pro (non-360) and have similar sound issues in Linux (multiple kernels and versions of SOF).

Maybe the 360 and non-360 have some kind of difference because the verb list from that Manjaro forum post never worked for me.

However I have succeeded in using QemuHDADump to get a (very long) list of verbs that actually do work -- now I can get sound on my Book2 Pro, but I would like that we can try to fix whatever is needed in the driver/upstream to remove these little workarounds :)

@lgirdwood I don't think its an issue to get the verbs again (they are already in the file and if they are working then that is all that this script/process would get out too from what I understand) but the issue is more about trying to narrow down exactly which verbs are actually "needed".

For example the smallest I have gotten my list down to is around 1,500 lines (yikes) but have a bit of a tough time trying to narrow it down at it seems there is some kind of cache which "holds on" to the settings for a while, even after restarts. Basically once I send in the verbs that work, the sound keeps "working" even after restarts and then after several hours or a day later I find that it seems to not be working anymore.

So my question is actually now, is there an easy way to "reset" the driver/hardware cache so that I can get a faster cycle to trial-and-error which verbs are really needed and then narrow the list down? Some kind of command or anything which I can run to clear this "cache" that appears to be there?

Thank you!

[lgirdwood]

@ujfalusi @bardliao any idea how to reset the HDA register cache here ?

[ujfalusi]

Once the right set of verbs identified for the device they can be integrated to sound/pci/hda/patch_realtek.c as quirk or fixup.
After that there will be no need for the script in user space.

[joshuagrisham]

Once the right set of verbs identified for the device they can be integrated to sound/pci/hda/patch_realtek.c as quirk or fixup. After that there will be no need for the script in user space.

Hi @ujfalusi this sounds great to me but still having a bit of trouble with being able to quickly test which verbs are really needed vs not. The issue is it takes some time for the cache to reset/clear so trying to narrow down 1500 verbs to just a few (5-10??) with only one attempt per day is a bit tricky 😆

I have tried a bit with using some of the sysfs files (https://www.kernel.org/doc/html/latest/sound/hd-audio/notes.html#hd-audio-reconfiguration) a bit like this:

$ systemctl --user stop pulseaudio.s*
$ sudo su
# cat /sys/class/sound/hwC0D0/init_pin_configs
0x12 0x411111f0
0x13 0x40000000
0x14 0x411111f0
0x17 0x90170110
0x18 0x04a11020
0x19 0x411111f0
0x1a 0x411111f0
0x1d 0x40630245
0x1e 0x411111f0
0x1f 0x411111f0
0x21 0x04211050
# echo 0x12 0x411111f0 > /sys/class/sound/hwC0D0/user_pin_configs
# cat /sys/class/sound/hwC0D0/user_pin_configs
0x12 0x411111f0
# echo 1 > /sys/class/sound/hwC0D0/reconfig

Every time I try to update /reconfig or /clear then everything just "freezes" and it never seems to finish.

After a while in the journal (dmesg or journalctl) I can see something like this:

[  734.517375] snd_hda_codec_realtek ehdaudio0D0: hda-codec: reconfiguring
[  968.061471] INFO: task bash:4817 blocked for more than 120 seconds.
[  968.061485]       Not tainted 5.15.0-47-generic thesofproject/sof#51-Ubuntu
[  968.061488] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[  968.061491] task:bash            state:D stack:    0 pid: 4817 ppid:  4816 flags:0x00004006
[  968.061500] Call Trace:
[  968.061503]  <TASK>
[  968.061509]  __schedule+0x23d/0x590
[  968.061519]  ? call_rcu+0xe/0x20
[  968.061529]  schedule+0x4e/0xc0
[  968.061533]  schedule_timeout+0x103/0x140
[  968.061538]  ? call_rcu+0xe/0x20
[  968.061543]  ? __cond_resched+0x1a/0x50
[  968.061547]  ? __dentry_kill+0x14a/0x190
[  968.061553]  __wait_for_common+0xab/0x150
[  968.061556]  ? usleep_range_state+0x90/0x90
[  968.061567]  wait_for_completion+0x24/0x30
[  968.061573]  snd_card_free+0xa0/0xb0 [snd]
[  968.061591]  soc_cleanup_card_resources+0x2c5/0x2e0 [snd_soc_core]
[  968.061624]  snd_soc_del_component_unlocked+0x135/0x170 [snd_soc_core]
[  968.061648]  snd_soc_unregister_component_by_driver+0x3b/0x60 [snd_soc_core]
[  968.061671]  devm_component_release+0x11/0x20 [snd_soc_core]
[  968.061706]  release_nodes+0x3d/0xb0
[  968.061712]  devres_release_all+0x9b/0xd0
[  968.061717]  __device_release_driver+0x1bb/0x2a0
[  968.061724]  device_release_driver+0x29/0x40
[  968.061729]  snd_hda_codec_reset+0x2a/0x70 [snd_hda_codec]
[  968.061752]  reconfig_store+0x47/0xa0 [snd_hda_codec]
[  968.061769]  dev_attr_store+0x14/0x30
[  968.061775]  sysfs_kf_write+0x3b/0x50
[  968.061782]  kernfs_fop_write_iter+0x138/0x1c0
[  968.061788]  new_sync_write+0x114/0x1b0
[  968.061795]  vfs_write+0x1d5/0x270
[  968.061798]  ksys_write+0x67/0xf0
[  968.061802]  __x64_sys_write+0x19/0x20
[  968.061805]  do_syscall_64+0x59/0xc0
[  968.061809]  ? fput+0x13/0x20
[  968.061813]  ? filp_close+0x60/0x70
[  968.061818]  ? exit_to_user_mode_prepare+0x37/0xb0
[  968.061824]  ? syscall_exit_to_user_mode+0x27/0x50
[  968.061828]  ? __x64_sys_close+0x11/0x50
[  968.061833]  ? do_syscall_64+0x69/0xc0
[  968.061836]  ? do_syscall_64+0x69/0xc0
[  968.061838]  entry_SYSCALL_64_after_hwframe+0x61/0xcb
[  968.061845] RIP: 0033:0x7f4b9db8da37
[  968.061850] RSP: 002b:00007fff3ab56e38 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
[  968.061856] RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007f4b9db8da37
[  968.061858] RDX: 0000000000000002 RSI: 00005589c83bfc40 RDI: 0000000000000001
[  968.061860] RBP: 00005589c83bfc40 R08: 00007f4b9dc4a460 R09: 000000007fffffff
[  968.061862] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000002
[  968.061864] R13: 00007f4b9dc93780 R14: 00007f4b9dc8f600 R15: 00007f4b9dc8ea00
[  968.061868]  </TASK>

But then again maybe I am trying to go about this totally wrong. 😆 So I guess back to my earlier question, is there a (relatively) easy way to reset the HDA verbs so that I can try to test different sets of verbs and narrow down the list so we can figure out what needs to be included in the fixup?

Thanks again!

[lgirdwood]

Hi @ujfalusi this sounds great to me but still having a bit of trouble with being able to quickly test which verbs are really needed vs not. The issue is it takes some time for the cache to reset/clear so trying to narrow down 1500 verbs to just a few (5-10??) with only one attempt per day is a bit tricky

Yeah, this sounds painful. Fwiw a lot of these 1500 could be volume ramps i.e. to prevent loud pops. I would check the verb list for writes of increasing values to the same verb ID and just use the last write for that verb. This should speed things up (but will pop atm). There may be increasing value writes to multiple verb IDs (e.g. for L/R spk or HP).

[Itaig10]

@joshuagrisham I am struggling with extracting the needed verbs with the non 360 model, can you please upload somewhere the list of the verbs? thanks!

[majosamaso]

I have the same 360 laptop and I tried months ago get a patch to solve speaker problems in kernel bugzilla https://bugzilla.kernel.org/show_bug.cgi?id=216023

Unfortunately, there is multiple issues like the big quantity of verbs needed to make it work, being unable to use snd-hda-intel early patching and even then, only the left speaker works. Only both work if you try initialize from windows and reset to linux.

The audio configuration carries until the computer is fully shutdown, reset isn't enough to clean state of audio card

[joshuagrisham]

Hi @Itaig10 I just threw my list into pastebin so you can see if you like here: https://pastebin.com/45ksYAXX

Just to state again, this list I got by using the QEMU method to actually run a new Windows instance using QEMU from within Linux, then inside of Windows, installing the soundcard drivers, playing audio from the virtual Windows environment (which worked!), and capturing the verbs using some combination of tools and processes that were linked in some of the other threads.

I have done some debugging the last few days with adding a sleep delay to each line with this file and found that the exact line which "turns on" left speaker is line 2249 and then the right speaker "turns on" at line 3857

Both happen exactly when this value is sent:

hda-verb /dev/snd/hwC0D0 0x20 0x4b0 0x11

But it is a bit strange, it seems almost like a sequence which needs to be preceded by something else. I have looked a bit to see what patterns seem to exist and have used meld to try and find what is really "different" between when the left speaker turns on and the right speaker turns on, and the best I could find is this:

At the beginning of the file seem to be some kind of ramps and other things happening which I have not quite fully figured out, but once you get somewhere past line 500-600 or so then there seems to be basically a "left speaker" sequence which turns the left on, followed by a "right speaker" sequence which turns the right on. These two "sides" (approx. 1600 lines each) seem to be almost exactly identical except I found a small sequence that seems to be unique for each one.

For the "left side" it happens between line 2173 and line 2182 in my file

hda-verb /dev/snd/hwC0D0 0x20 0x500 0x23
hda-verb /dev/snd/hwC0D0 0x20 0x423 0xa6
hda-verb /dev/snd/hwC0D0 0x20 0x400 0x0
hda-verb /dev/snd/hwC0D0 0x20 0x400 0x64
hda-verb /dev/snd/hwC0D0 0x20 0x4b0 0x11
hda-verb /dev/snd/hwC0D0 0x20 0x500 0x23
hda-verb /dev/snd/hwC0D0 0x20 0x423 0xa6
hda-verb /dev/snd/hwC0D0 0x20 0x400 0x0
hda-verb /dev/snd/hwC0D0 0x20 0x400 0x64
hda-verb /dev/snd/hwC0D0 0x20 0x4b0 0x11

Followed eventually as said that on line 2249 the speaker turns on.

And then for the "right side" it is between line 3672 and 3680 of my file:

hda-verb /dev/snd/hwC0D0 0x20 0x423 0x91
hda-verb /dev/snd/hwC0D0 0x20 0x400 0x0
hda-verb /dev/snd/hwC0D0 0x20 0x400 0x3
hda-verb /dev/snd/hwC0D0 0x20 0x4b0 0x11
hda-verb /dev/snd/hwC0D0 0x20 0x500 0x23
hda-verb /dev/snd/hwC0D0 0x20 0x423 0x91
hda-verb /dev/snd/hwC0D0 0x20 0x400 0x0
hda-verb /dev/snd/hwC0D0 0x20 0x400 0x3
hda-verb /dev/snd/hwC0D0 0x20 0x4b0 0x11

And then the speaker turns on at line 3857.

I have tried to do a bit what @lgirdwood suggested and try to take the max value from what seem like various ramps, then take these two different sequences plus some group of the sequence before the speakers "turns on" -- few attempts so far but still no dice as of yet. If I push the whole file in, then I have sound and that is great! But does not feel super close yet to identifying actually which verb values are needed, and to pinpoint what would need to be fixed in the kernel...

Also as a small aside, my perception is that even after all of this, the right side speaker is slightly quieter than the left side.. if I drag the balance slider a bit towards the right then I feel like I get a bit more "balanced" sound.

Since this is a very part-time "hobby" for me (meaning that my time is usually a bit limited!), my hope is that someone can maybe pick up from what I have here and we can find a way forward together somehow! 😎