search

thesofproject / linux

Linux kernel source tree
Other
89 stars 128 forks source link

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

Open datmischa opened 2 years ago

datmischa commented 2 years ago

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).

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

dmesg dmesg_grep_sof.txt dmesg.txt

sof-logger freezes my system

alsa-info.txt

plbossart commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

@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 commented 1 year ago

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 commented 1 year ago

@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.

ghost commented 1 year ago

This issue seems to affect other Galaxy Book Models too

joshuagrisham commented 1 year ago

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 commented 1 year ago

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

ujfalusi commented 1 year ago

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 commented 1 year ago

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 :laughing:

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. :laughing: 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 commented 1 year ago

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 commented 1 year ago

@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 commented 1 year ago

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 commented 1 year ago

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! :sunglasses:

drewdrew0 commented 1 year ago

So - the verbs that @joshuagrisham posted here saved me. I have the Galaxy Book2 Pro Arc graphics version (NP950XEE), and none of the other fixes or verbs from the various forums worked at all. So here's my question:

I noticed when it first worked, as others here do, that the right-side volume was about 10% less. No biggie at all. But during testing, I shutdown to reset, confirmed I had no sound, then re-ran the verbs, getting sound again. But this time the right-side was like 50% quieter. Is it possible these verbs are altering the volume, and leaving the right slightly lower each time it runs - Has anyone else noticed this? And if so, does it reset ever, when, how?

In the meantime, I am going to apply these verbs only when necessary (as opposed to installing as a service as planned), and cross my fingers that there are some updates on this issue/thread... Cause I tried to go down the QEMU route myself, and got endlessly stuck, so you all are better men than me ;)

mkdolan commented 1 year ago

I am also having the same exact issue with the non-360 Galaxy Book2 Pro with Ubuntu 22.04 with all the latest package and kernel updates. Bluetooth or headphone audio works fine, but nothing from the speakers. If there's anything I can do to help run a test, or provide any outputs, just let me know.

grovera-md commented 1 year ago

I am also having the same issue with my Samsung Galaxy Book 2 Pro 360 running Linux Mint 21 Cinnamon (Kernel: 5.15.0-53-generic). System information data: Audio: Device-1: Intel Alder Lake PCH-P High Definition Audio vendor: Samsung Co driver: sof-audio-pci-intel-tgl Sound Server-1: ALSA v: k5.15.0-53-generic running: yes Sound Server-2: PulseAudio v: 15.99.1 running: yes Sound Server-3: PipeWire v: 0.3.48 running: yes

I hope that a fix will be available soon

lgirdwood commented 1 year ago

@bardliao anyone from Realtek that should be added here? I think Realtek are the only folks who can solve the codec/amp config.

bardliao commented 1 year ago

@bardliao anyone from Realtek that should be added here? I think Realtek are the only folks who can solve the codec/amp config.

kailang@realtek.com, but I can't remember his github account.

tencnivel commented 1 year ago

same problem for me (non 360)

[soso@pc1234 ~]$ inxi -A
Audio:
  Device-1: Intel Alder Lake PCH-P High Definition Audio
    driver: sof-audio-pci-intel-tgl
  Sound API: ALSA v: k6.0.10-300.fc37.x86_64 running: yes
  Sound Server-1: PipeWire v: 0.3.61 running: yes
[soso@pc1234 ~]$ uname -a
Linux pc-131.home 6.0.10-300.fc37.x86_64 #1 SMP PREEMPT_DYNAMIC Sat Nov 26 16:55:13 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
TompeHarshavardhan commented 1 year ago

I am also having the same exact issue with the non-360 Galaxy Book2 Pro

Audio:
  Device-1: Intel Alder Lake PCH-P High Definition Audio
    driver: sof-audio-pci-intel-tgl
  Sound Server-1: ALSA v: k5.15.0-56-generic running: yes
  Sound Server-2: PulseAudio v: 15.99.1 running: yes
  Sound Server-3: PipeWire v: 0.3.48 running: yes
uname -a
Linux Harshs-Galaxybook 5.15.0-56-generic #62-Ubuntu SMP Tue Nov 22 19:54:14 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
t-trmg commented 1 year ago

Just another +1 to having this issue with a Samsung Galaxy Book2 Pro 360 (NP950QED-KA1US). Just installed Ubuntu 20.04 and fully updated said install via apt update && apt dist-upgrade.

Output from 'lspci -kvv'

00:1f.3 Multimedia audio controller: Intel Corporation Alder Lake PCH-P High Definition Audio Controller (rev 01)
    DeviceName: Onboard - Sound
    Subsystem: Samsung Electronics Co Ltd Device c1ac
    Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
    Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
    Latency: 32, Cache Line Size: 64 bytes
    Interrupt: pin A routed to IRQ 187
    IOMMU group: 13
    Region 0: Memory at 601d190000 (64-bit, non-prefetchable) [size=16K]
    Region 4: Memory at 601d000000 (64-bit, non-prefetchable) [size=1M]
    Capabilities: [50] Power Management version 3
        Flags: PMEClk- DSI- D1- D2- AuxCurrent=55mA PME(D0-,D1-,D2-,D3hot+,D3cold+)
        Status: D3 NoSoftRst+ PME-Enable+ DSel=0 DScale=0 PME-
    Capabilities: [80] Vendor Specific Information: Len=14 <?>
    Capabilities: [60] MSI: Enable+ Count=1/1 Maskable- 64bit+
        Address: 00000000fee00a38  Data: 0000
    Kernel driver in use: sof-audio-pci-intel-tgl
    Kernel modules: snd_hda_intel, snd_sof_pci_intel_tgl

Output of inxi -A

Audio:
  Device-1: Intel Alder Lake PCH-P High Definition Audio driver: sof-audio-pci-intel-tgl
  Sound Server-1: ALSA v: k5.15.0-56-generic running: yes
  Sound Server-2: PulseAudio v: 15.99.1 running: yes
  Sound Server-3: PipeWire v: 0.3.48 running: yes

Output of uname -a

Linux GalaxyBook2 5.15.0-56-generic #62-Ubuntu SMP Tue Nov 22 19:54:14 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
t-trmg commented 1 year ago

@joshuagrisham your perception is not wrong. Looks like running through the verb list you shared on Oct 16 also works for me, and as you observed the left channel is noticeably quieter. It seems if I adjust balance to the left about 1/3rd-ish of the way between center and full left it sounds even.

t-trmg commented 1 year ago

@bardliao anyone from Realtek that should be added here? I think Realtek are the only folks who can solve the codec/amp config.

kailang@realtek.com, but I can't remember his github account.

If my sleuthing is correct, it is @kailangyang. Hopefully I am correct. :grin:.

influenist commented 1 year ago

Hi guys, same issue here with the xiaomi notebook pro x 15 (ALC 298). Sound only coming from 2 speakers out of 4, with 20%. Rear ones don't get any sound at all.

http://alsa-project.org/db/?f=e4477f3727b1df458e1647d10a48cba2f94b2112

hamfirst commented 1 year ago

Can confirm that the verbs by joshuagrisham get audio working on Linux on the Galaxy Book 3 Pro 360

wcota commented 1 year ago

I have the Samsung NP950XEE-XA1BR model with ALC298 and the verbs by @joshuagrisham worked fine for the left speaker. However, the right one is very low. It was an improvement since nothing else worked. It would be great to fix this and have both speakers working similarly!

I noticed when it first worked, as others here do, that the right-side volume was about 10% less. No biggie at all. But during testing, I shutdown to reset, confirmed I had no sound, then re-ran the verbs, getting sound again. But this time the right-side was like 50% quieter. Is it possible these verbs are altering the volume, and leaving the right slightly lower each time it runs - Has anyone else noticed this? And if so, does it reset ever, when, how?

I noticed the same thing in mine, @drewdrew0!

emilianodellacasa commented 1 year ago

I just tried @joshuagrisham verbs on my NP958XED-KA1IT and sound is working now, even after a reboot!

I am not noticing any problem with the volumes, but I will periodically check.

Thanks!

ItzDerock commented 1 year ago

Tried the verbs from @joshuagrisham on my Galaxy Book3 Ultra (NP960XFH) and sound is working perfectly.

AP-XD commented 1 year ago

Sound works on Samsung galaxy book 3 pro 360 with the verbs provided by @joshuagrisham but left channel has lower audio than right one

wcota commented 1 year ago

Sound works on Samsung galaxy book 3 pro 360 with the verbs provided by @joshuagrisham but left channel has lower audio than right one

Same here, and every time I suspend or hibernate, I have to do it again with the left and right levels becoming even more different

AP-XD commented 1 year ago

I am actually using OpenSUSE Tumbleweed. Here if I once shift the levels it remembers and adjusts it perfectly & as for the repeated execution I have set a CRON JOB. Here is the link to the detailed guide which I made, and also the reddit post.

quentinalbertone commented 1 year ago

Same here

Sound works on Samsung galaxy book 3 pro 360 with the verbs provided by @joshuagrisham but left channel has lower audio than right one

Same here :sweat:

crinavar commented 1 year ago

Thanks for the solution, although the sound is less quality than in windows, and with less audio on the left side, it is far better than not having sound.

Does anyone know if a fix is in the works? Also, could this be related to this other sound problem in the following URL? https://bbs.archlinux.org/viewtopic.php?id=285121

nottoosmart commented 1 year ago

Galaxy Book3 Pro 360 here and It seems that every time I run this the volume gets less and less. I am so tired of Windows but have to keep it just for the audio and video. After sound we can work on getting the webcams working unless someone has a fix for that already.

wcota commented 11 months ago

So, bad news for me. Some days ago the left speaker started to become very strange and with low quality, even on Windows. Today, the left speaker suddenly stopped working and I felt a burning smell coming from it on the laptop... now I only have the right speaker working :( I'll try contacting Samsung support and see if there's a solution. (Samsung Galaxy Book2 Pro, NP950XEE-XA1BR)

crinavar commented 11 months ago

So, bad news for me. Some days ago the left speaker started to become very strange and with low quality, even on Windows. Today, the left speaker suddenly stopped working and I felt a burning smell coming from it on the laptop... now I only have the right speaker working :( I'll try contacting Samsung support and see if there's a solution. (Samsung Galaxy Book2 Pro, NP950XEE-XA1BR)

Let's hope they replace your laptop. Is there any chance that the verbs were part of the cause of your burned speaker?

seanpk commented 9 months ago

I'm posting to confirm that this affects more than the Samsung device and that solution works on other devices too.

I did not have sound on my LG gram 16 (16Z90R-A) and found this thread through this fedora forum post and then the referenced GH repo.

But after editing (s/hwC0D0/hwC2D0/) the device in the script, I now have sound.

I am on Pop!_OS with:

$ uname -a
Linux bigg 6.5.6-76060506-generic #202310061235~1697396945~22.04~9283e32 SMP PREEMPT_DYNAMIC Sun O x86_64 x86_64 x86_64 GNU/Linux
$ apt show firmware-sof-signed
Package: firmware-sof-signed
Version: 2.0-1ubuntu4.1
Priority: optional
Section: restricted/kernel
Source: firmware-sof
Origin: Ubuntu
archdsp commented 9 months ago

I am a Samsung Galaxy Book 3 Ultra user. (Using ALC298 chip, alsa driver) I use Archlinux with 6.5.X > Kernel with KDE and duaboot with ClearLinux with Gnome. First i ran script, sound only comming out from left speaker and sound quality was very low but system speaker was not when test with amixer and aplay.

But after reboot to Clearlinux, both left and right speaker works fine and loud also audio quality was good. I was supprised so i directly reboot to archlinux and confirmed speaker works fine same as on ClearLinux.

Thanks to @joshuagrisham ! You save my day. I appreciate your effort.

Archlinux version

Linux dsparch-laptop 6.5.9-arch2-1 #1 SMP PREEMPT_DYNAMIC Thu, 26 Oct 2023 00:52:20 +0000 x86_64 GNU/Linux

aplay output

[dsparch@dsparch-laptop ~]$ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: PCH [HDA Intel PCH], device 0: Generic Analog [Generic Analog]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: PCH [HDA Intel PCH], device 3: Generic Digital [Generic Digital]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
[dsparch@dsparch-laptop ~]$ ls /dev/snd/
by-path  controlC0  hwC0D0  hwC0D2  pcmC0D0c  pcmC0D0p  pcmC0D3p  seq  timer
EverardNisse commented 6 months ago

https://asus-linux.org/blog/sound-2021-01-11/

Hey, this seems like a good resource on supporting new sound devices. On skimming, it seems like one needs to:

  1. Get Windows dumps via VM or installation Change sound configurations (speaker on-off, mic on-off, etc) and dump on each step
  2. Spot the differences with Linux dumps
  3. Write a local firmware patch to unify changes and keep testing
plbossart commented 6 months ago

that was pretty much the recommendation from day1...

https://thesofproject.github.io/latest/getting_started/intel_debug/suggestions.html#reverse-engineer-the-windows-audio-driver

EverardNisse commented 6 months ago

You kinda did, but did I scroll down a bit to read more? Nope :smile:

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

Anyways, let's see what can be done

alekfrohlich commented 6 months ago

Same problem here with my Samsung Galaxy Book 2 Pro running on fedora 38, waiting for a more definitive solution than the verb list.

mkdolan commented 6 months ago

Looks like the new kernel release has some SOF updates, but I haven't tested it. Due to the sounds, screen brightness, and other issues, I had replaced my Galaxy Book 2 Pro with another laptop that more fully supports Linux out of the box.

https://www.phoronix.com/news/Linux-6.8-Sound

EverardNisse commented 6 months ago

Looks like the new kernel release has some SOF updates

Like a sea of commits each more confusing than the last. We'll see if it makes an impact.

Till then, some mildly interesting developments from following SOF: Reverse engineer the Windows audio driver on Samsung Book3 360 Pro and Arch.

The device ships with Win11 and drivers are downloaded manually via 'Samsung Update' (you enter your hardware device id). The provided driver produces sound cracks on a Win10 VM so a Win11 VM is required with TPM 2.0, secure boot and 64 GB storage. The qemu Arch package produced events without need to recompile with trace support. Here's the modified qemu script:

startvm.sh ```bash #!/bin/bash if ! [ -f /tmp/swtpm ]; then mkdir /tmp/swtpm chown tss:root /tmp/swtpm swtpm_setup --tpmstate /tmp/swtpm --create-ek-cert --create-platform-cert --tpm2 fi swtpm socket --tpm2 --tpmstate dir=/tmp/swtpm --ctrl type=unixio,path=/tmp/swtpm-sock -d qemu-system-x86_64 \ -enable-kvm \ -smp 4 \ -m 8G \ -name Win11 \ -machine q35,accel=kvm \ -hda win11.img \ -cdrom win11.iso \ -device vfio-pci,host=0000:00:1f.0,x-no-mmap=true \ -device vfio-pci,host=0000:00:1f.3,x-no-mmap=true \ -device vfio-pci,host=0000:00:1f.4,x-no-mmap=true \ -device vfio-pci,host=0000:00:1f.5,x-no-mmap=true \ -trace events=./events.txt \ -monitor stdio \ -chardev socket,id=chrtpm,path=/tmp/swtpm-sock \ -tpmdev emulator,id=tpm0,chardev=chrtpm \ -device tpm-tis,tpmdev=tpm0 \ -drive if=pflash,format=raw,readonly=on,file="/usr/share/edk2/x64/OVMF_CODE.secboot.fd" \ -drive if=pflash,format=raw,file="./OVMF_VARS.fd" \ ```
Results Regardless of method used the driver was required but even with the driver(s) speaker volume couldn't be adjusted via keyboard buttons or software (unless to mute or by adjusting levels for singular apps) 1. Starting via script Sound plays through speakers but has cracks 2. Starting via ```virt-manager``` with a mostly auto-generated config and the same disk image Sound plays without issues (besides volume adjustment described above) I am yet to find the difference between these two methods, so here's the command virt-manager uses (from /var/log/libvirt/qemu/win11.log). Alternatively is there a way to log events (like the script does) with ```virt-manager``` without running the command it uses?
libvirt qemu command ```bash 2024-01-17 00:00:00.000+0000: starting up libvirt version: 10.0.0, qemu version: 8.2.0, kernel: 6.7.0-arch3-1, hostname: hostname LC_ALL=C \ PATH=/usr/local/sbin:/usr/local/bin:/usr/bin \ USER=root \ HOME=/var/lib/libvirt/qemu/domain-6-win11 \ XDG_DATA_HOME=/var/lib/libvirt/qemu/domain-6-win11/.local/share \ XDG_CACHE_HOME=/var/lib/libvirt/qemu/domain-6-win11/.cache \ XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain-6-win11/.config \ /usr/bin/qemu-system-x86_64 \ -name guest=win11,debug-threads=on \ -S \ -object '{"qom-type":"secret","id":"masterKey0","format":"raw","file":"/var/lib/libvirt/qemu/domain-6-win11/master-key.aes"}' \ -blockdev '{"driver":"file","filename":"/usr/share/edk2/x64/OVMF_CODE.secboot.fd","node-name":"libvirt-pflash0-storage","auto-read-only":true,"discard":"unmap"}' \ -blockdev '{"node-name":"libvirt-pflash0-format","read-only":true,"driver":"raw","file":"libvirt-pflash0-storage"}' \ -blockdev '{"driver":"file","filename":"/var/lib/libvirt/qemu/nvram/win11_VARS.fd","node-name":"libvirt-pflash1-storage","auto-read-only":true,"discard":"unmap"}' \ -blockdev '{"node-name":"libvirt-pflash1-format","read-only":false,"driver":"raw","file":"libvirt-pflash1-storage"}' \ -machine pc-q35-8.2,usb=off,vmport=off,smm=on,dump-guest-core=off,memory-backend=pc.ram,pflash0=libvirt-pflash0-format,pflash1=libvirt-pflash1-format,hpet=off,acpi=on \ -accel kvm \ -cpu host,migratable=on,hv-time=on,hv-relaxed=on,hv-vapic=on,hv-spinlocks=0x1fff \ -global driver=cfi.pflash01,property=secure,value=on \ -m size=8388608k \ -object '{"qom-type":"memory-backend-ram","id":"pc.ram","size":8589934592}' \ -overcommit mem-lock=off \ -smp 4,sockets=4,cores=1,threads=1 \ -uuid e3f88c50-9265-40b3-b281-3635bcfec9d8 \ -no-user-config \ -nodefaults \ -chardev socket,id=charmonitor,fd=32,server=on,wait=off \ -mon chardev=charmonitor,id=monitor,mode=control \ -rtc base=localtime,driftfix=slew \ -global kvm-pit.lost_tick_policy=delay \ -no-shutdown \ -global ICH9-LPC.disable_s3=1 \ -global ICH9-LPC.disable_s4=1 \ -boot strict=on \ -device '{"driver":"pcie-root-port","port":16,"chassis":1,"id":"pci.1","bus":"pcie.0","multifunction":true,"addr":"0x2"}' \ -device '{"driver":"pcie-root-port","port":17,"chassis":2,"id":"pci.2","bus":"pcie.0","addr":"0x2.0x1"}' \ -device '{"driver":"pcie-root-port","port":18,"chassis":3,"id":"pci.3","bus":"pcie.0","addr":"0x2.0x2"}' \ -device '{"driver":"pcie-root-port","port":19,"chassis":4,"id":"pci.4","bus":"pcie.0","addr":"0x2.0x3"}' \ -device '{"driver":"pcie-root-port","port":20,"chassis":5,"id":"pci.5","bus":"pcie.0","addr":"0x2.0x4"}' \ -device '{"driver":"pcie-root-port","port":21,"chassis":6,"id":"pci.6","bus":"pcie.0","addr":"0x2.0x5"}' \ -device '{"driver":"pcie-root-port","port":22,"chassis":7,"id":"pci.7","bus":"pcie.0","addr":"0x2.0x6"}' \ -device '{"driver":"pcie-root-port","port":23,"chassis":8,"id":"pci.8","bus":"pcie.0","addr":"0x2.0x7"}' \ -device '{"driver":"pcie-root-port","port":24,"chassis":9,"id":"pci.9","bus":"pcie.0","multifunction":true,"addr":"0x3"}' \ -device '{"driver":"pcie-root-port","port":25,"chassis":10,"id":"pci.10","bus":"pcie.0","addr":"0x3.0x1"}' \ -device '{"driver":"pcie-root-port","port":26,"chassis":11,"id":"pci.11","bus":"pcie.0","addr":"0x3.0x2"}' \ -device '{"driver":"pcie-root-port","port":27,"chassis":12,"id":"pci.12","bus":"pcie.0","addr":"0x3.0x3"}' \ -device '{"driver":"pcie-root-port","port":28,"chassis":13,"id":"pci.13","bus":"pcie.0","addr":"0x3.0x4"}' \ -device '{"driver":"pcie-root-port","port":29,"chassis":14,"id":"pci.14","bus":"pcie.0","addr":"0x3.0x5"}' \ -device '{"driver":"pcie-root-port","port":30,"chassis":15,"id":"pci.15","bus":"pcie.0","addr":"0x3.0x6"}' \ -device '{"driver":"pcie-pci-bridge","id":"pci.16","bus":"pci.1","addr":"0x0"}' \ -device '{"driver":"qemu-xhci","p2":15,"p3":15,"id":"usb","bus":"pci.3","addr":"0x0"}' \ -device '{"driver":"virtio-serial-pci","id":"virtio-serial0","bus":"pci.4","addr":"0x0"}' \ -blockdev '{"driver":"file","filename":"/home/user/win-vm/win11.img","node-name":"libvirt-1-storage","auto-read-only":true,"discard":"unmap"}' \ -blockdev '{"node-name":"libvirt-1-format","read-only":false,"driver":"qcow2","file":"libvirt-1-storage","backing":null}' \ -device '{"driver":"ide-hd","bus":"ide.0","drive":"libvirt-1-format","id":"sata0-0-0","bootindex":1}' \ -netdev '{"type":"tap","fd":"33","id":"hostnet0"}' \ -device '{"driver":"e1000e","netdev":"hostnet0","id":"net0","mac":"52:54:00:86:e0:1b","bus":"pci.2","addr":"0x0"}' \ -chardev pty,id=charserial0 \ -device '{"driver":"isa-serial","chardev":"charserial0","id":"serial0","index":0}' \ -chardev spicevmc,id=charchannel0,name=vdagent \ -device '{"driver":"virtserialport","bus":"virtio-serial0.0","nr":1,"chardev":"charchannel0","id":"channel0","name":"com.redhat.spice.0"}' \ -chardev socket,id=chrtpm,path=/run/libvirt/qemu/swtpm/6-win11-swtpm.sock \ -tpmdev emulator,id=tpm-tpm0,chardev=chrtpm \ -device '{"driver":"tpm-crb","tpmdev":"tpm-tpm0","id":"tpm0"}' \ -device '{"driver":"usb-tablet","id":"input0","bus":"usb.0","port":"1"}' \ -audiodev '{"id":"audio1","driver":"spice"}' \ -spice port=5900,addr=127.0.0.1,disable-ticketing=on,image-compression=off,seamless-migration=on \ -device '{"driver":"qxl-vga","id":"video0","max_outputs":1,"ram_size":67108864,"vram_size":67108864,"vram64_size_mb":0,"vgamem_mb":16,"bus":"pcie.0","addr":"0x1"}' \ -global ICH9-LPC.noreboot=off \ -watchdog-action reset \ -chardev spicevmc,id=charredir0,name=usbredir \ -device '{"driver":"usb-redir","chardev":"charredir0","id":"redir0","bus":"usb.0","port":"2"}' \ -chardev spicevmc,id=charredir1,name=usbredir \ -device '{"driver":"usb-redir","chardev":"charredir1","id":"redir1","bus":"usb.0","port":"3"}' \ -device '{"driver":"vfio-pci","host":"0000:00:1f.3","id":"hostdev0","bus":"pci.16","addr":"0x1"}' \ -device '{"driver":"vfio-pci","host":"0000:00:1f.0","id":"hostdev1","bus":"pci.16","addr":"0x2"}' \ -device '{"driver":"vfio-pci","host":"0000:00:1f.4","id":"hostdev2","bus":"pci.16","addr":"0x3"}' \ -device '{"driver":"vfio-pci","host":"0000:00:1f.5","id":"hostdev3","bus":"pci.16","addr":"0x4"}' \ -device '{"driver":"virtio-balloon-pci","id":"balloon0","bus":"pci.5","addr":"0x0"}' \ -sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \ -msg timestamp=on ```
So, still trying to dump verbs on my machine even if they turn up to be the same as what's already been posted, as an exercise.
EverardNisse commented 6 months ago

The lines that removed the cracking/popping sounds, taken from virt-manager's qemu command are:

    -spice port=5900,addr=127.0.0.1,disable-ticketing=on,image-compression=off,seamless-migration=on \
    -device qxl-vga \

Guess a spice audio driver is auto-loaded when using -spice which spicy or any other client then uses and it is somehow superior than to just pass the devices.

Anyways now the speakers work with a likely native quality, tho volume level can't be adjusted, and if we modify -trace events=./events.txt,file=win11.log the OS startup process happily spews out ~11K lines of:

...
vfio_region_write  (0000:00:1f.3:region0+0x704, 0x0, 4)
vfio_region_write  (0000:00:1f.3:region0+0x704, 0x0, 4)
vfio_region_write  (0000:00:1f.3:region0+0x804, 0xc0000000, 4)
vfio_region_write  (0000:00:1f.3:region0+0x704, 0x0, 4)
vfio_region_write  (0000:00:1f.3:region0+0x1048, 0xe9, 1)
vfio_region_write  (0000:00:1f.3:region4+0xd8, 0x20701000, 4)
vfio_region_write  (0000:00:1f.3:region4+0xd0, 0xc3000000, 4)
vfio_region_write  (0000:00:1f.3:region0+0x20, 0x40000000, 4)
vfio_region_write  (0000:00:1f.3:region4+0xd4, 0x80000000, 4)
vfio_region_write  (0000:00:1f.3:region4+0xc0, 0xe3000000, 4)

So, VM setup done??? and now to capture verbs on host/VM like in the guides, parse and diff the data, etc

edit: VM setup done but seems like qemu does not easily support reading the CORB / RIRB Intel HDA buffers. The patched qemu from the guides adds quick support for it, but is indeed old and hacky. Gonna work on a way to access the buffers again and see where it goes.

EverardNisse commented 6 months ago

From old and hacky, to new and hacky. I managed to rebase the commits from jcs/qemu to the latest qemu branch and rebuild the package. The project has just moved code around and the patch we use independently filters and parses every vfio memory read/write so it wasn't too hard.

Here's dumps from both OSs, the Windows one parsed through cleanverbs.py as well

linux-dump.txt win-boot-dump-verbs.txt win-boot-dump.txt

One can apply the verbs and whittle them down at their own tiny risk, but it's better to go through the rest of the process, better outlined at https://asus-linux.org/blog/sound-2021-01-11/. Currently I'm trying to figure out the pincfg and take multiple dumps.

EverardNisse commented 6 months ago

Managed to get speakers working on the Book3 Pro 360!

If you wish to replicate the result, install alsa-tools and run the first 165 verbs from my win-boot-dump-verbs.txt via applyverbs.py. Sound quality can't be vouched for yet (bass a bit quiet compared to VM imo).

After verb 165 the left speaker stops working. Somewhere between lines 165-5600 both speakers stop working. Note that both speakers start working before line 165 but are quiet / not playing high frequencies. This is likely the reason for all the patchy results among users / models - some of the verbs are extraneous or in conflict with Linux.

@joshuagrisham

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?

The fastest way I've found is to apply the verbs dumped from a VM boot or run and shutdown the VM. Also dynamically unbinding the pci devices via virsh contributes to speed.

startvm.sh ```bash #!/bin/bash # Detach all the devices in the IOMMU group virsh nodedev-detach pci_0000_00_1f_0 virsh nodedev-detach pci_0000_00_1f_3 virsh nodedev-detach pci_0000_00_1f_4 virsh nodedev-detach pci_0000_00_1f_5 # Start a TPM2.0 software emulator if ! [ -f /tmp/swtpm ]; then mkdir /tmp/swtpm chown tss:root /tmp/swtpm swtpm_setup --tpmstate /tmp/swtpm --create-ek-cert --create-platform-cert --tpm2 fi swtpm socket --tpm2 --tpmstate dir=/tmp/swtpm --ctrl type=unixio,path=/tmp/swtpm-sock -d # Start the VM qemu-system-x86_64 \ -enable-kvm \ -smp 4 \ -m 8G \ -name Win11 \ -machine q35,accel=kvm \ -hda win11.img \ -cdrom win11.iso \ -device vfio-pci,host=0000:00:1f.0,x-no-mmap=true \ -device vfio-pci,host=0000:00:1f.3,x-no-mmap=true \ -device vfio-pci,host=0000:00:1f.4,x-no-mmap=true \ -device vfio-pci,host=0000:00:1f.5,x-no-mmap=true \ -trace events=./events.txt,file=test.log \ -monitor stdio \ -chardev socket,id=chrtpm,path=/tmp/swtpm-sock \ -tpmdev emulator,id=tpm0,chardev=chrtpm \ -device tpm-tis,tpmdev=tpm0 \ -drive if=pflash,format=raw,readonly=on,file="/usr/share/edk2/x64/OVMF_CODE.secboot.fd" \ -drive if=pflash,format=raw,file="./OVMF_VARS.fd" \ -spice port=5900,addr=127.0.0.1,disable-ticketing=on,image-compression=off,seamless-migration=on \ -device qxl-vga # Connect to the display with a spice client like 'spicy' # Quit VM by entering system_powerdown in the Qemu console # Reattach devices to host virsh nodedev-reattach pci_0000_00_1f_0 virsh nodedev-reattach pci_0000_00_1f_3 virsh nodedev-reattach pci_0000_00_1f_4 virsh nodedev-reattach pci_0000_00_1f_5 # Kill swtpm daemon process killall swtpm ```

This didn't provide functionality but here's some info on getting the Windows pin configuration aka pincfg aka 7.3.3.31 Configuration Default in the Intel HDA specification:

  1. RtHDDump_V236.zip Link is dead but found it at https://people.canonical.com/~hwang4/rtdump/ Crashes the VM (10 or 11) with a segfault when ran.
  2. RtConfig.zip Yet another closed source developer utility but it did produce a list 
    0x13 40000000
0x14 411111F0
0x17 90170110
0x18 04A11020
0x19 411111F0
0x1A 411111F0
0x1D 40630245
0x1E 411111F0
0x1F 411111F0
0x21 04211050

    They're the same values as Pin Default from the Linux dump. Since the tutorial is about finding differences from the defaults it makes me wonder if this is the desired result.

j-m-harris commented 6 months ago

Managed to get speakers working on the Book3 Pro 360!

Great work @EverardNisse !

I've dumped the HDA verbs to try and get speakers working on a Razer laptop, but without success so far: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/2011385/comments/34

I suspected the pin settings might be at fault as well, will take a look at what you've done here.

phush0 commented 5 months ago

@j-m-harris I have same dump for Razer Blade 14 2023, but I also can not make it work. Pin setting that differ are for microphones and detection for headphone jack. Which are not making any difference for sound play.