[BUG] Samsung Galaxy Book2 Pro 360 no sound through speaker #4055
Comments
|
This is likely a codec and amplifier issue, see suggestions to double-check if this also happens with the legacy HDaudio driver. |
|
I finally got my speakers working. Steps to reproduce I have to rerun the script every time I restart/wake the PC from sleep. |
|
@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 0x10Fwiw verb 0x500 looks like it could be a volume ramp (and maybe some others could be too). |
|
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. |
|
@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. |
|
This issue seems to affect other Galaxy Book Models too |
|
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! |
|
Once the right set of verbs identified for the device they can be integrated to |
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: 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 ( 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! |
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). |
|
@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! |
|
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 |
|
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 0x11But 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 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: 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! 😎 |
|
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 ;) |
|
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. |
|
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). I hope that a fix will be available soon |
|
@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. |
|
same problem for me (non 360) |
|
I am also having the same exact issue with the non-360 Galaxy Book2 Pro |
|
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 Output from 'lspci -kvv' Output of Output of |
|
@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. |
If my sleuthing is correct, it is @kailangyang. Hopefully I am correct. 😁. |
|
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 |
|
Can confirm that the verbs by joshuagrisham get audio working on Linux on the Galaxy Book 3 Pro 360 |
|
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 the same thing in mine, @drewdrew0! |
|
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! |
|
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? |
|
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. |
|
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. |
Let's hope they replace your laptop. Is there any chance that the verbs were part of the cause of your burned speaker? |
|
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 ( I am on Pop!_OS with: |
|
I am a Samsung Galaxy Book 3 Ultra user. (Using ALC298 chip, alsa driver) 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/Linuxaplay 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 |
|
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:
|
|
that was pretty much the recommendation from day1... |
|
You kinda did, but did I scroll down a bit to read more? Nope 😄
Anyways, let's see what can be done |
|
Same problem here with my Samsung Galaxy Book 2 Pro running on fedora 38, waiting for a more definitive solution than the verb list. |
|
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. |
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 startvm.sh#!/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" \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)
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 libvirt qemu command2024-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=onSo, 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. |
|
The lines that removed the cracking/popping sounds, taken from virt-manager's qemu command are: Guess a spice audio driver is auto-loaded when using Anyways now the speakers work with a likely native quality, tho volume level can't be adjusted, and if we modify So, VM setup done??? edit: VM setup done but seems like qemu does not easily support reading the CORB / RIRB Intel HDA buffers. |
|
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 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. |
|
Managed to get speakers working on the Book3 Pro 360! If you wish to replicate the result, install 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.
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 startvm.sh#!/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 swtpmThis didn't provide functionality but here's some info on getting the Windows pin configuration aka pincfg aka
They're the same values as |
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. |
|
@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. |
Do you mind uploading the dumps? I am also considering of creating them. Did you use RtHDDump or QEMU? |
Sure, dumped from QEMU using instructions based on https://github.com/Conmanx360/QemuHDADump/tree/master Converted using https://github.com/Conmanx360/ca0132-tools |
|
Thank you, then I get an idea, what to expect, when I try it on my blade. |
|
This fix is working for me on a Razer Blade 16 - RZ09-0483: |
The same. Fix working on the Razer Blade 16 running Arch Linux. |
Same, working on a Razer Blade 18 running Arch. Audio is pretty tinny but that's not a dealbreaker, just glad to have it at all! |
|
Yes works! ❤️ |
|
Hello all - I have taken the verbs provided by @joshuagrisham and turned them into a working kernel patch! The verbs themselves can't be minimized that much from my experiments. There seems to be a few categories of them
This takes the value 0x4408 and writes it to register 0x82
Based on this example: https://patchwork.kernel.org/project/alsa-devel/patch/441231b80626cca3862320ff8b8d35430234518c@ap2c.com/#25337697 It appears that there's some back and forth communication between the chip and the driver in that after writing out a block of data in register 0x23 - 0x26. You can see in the verbs it's always writing out 0xb011 or 0xb017 to 0x26, but looking at the stored values through it appears that the 0x0010 bit is always set back to 0. Using this information, I tried eliminating a lot of the initial register queries of this type which worked My guess is that the verb sniffer doesn't track "get coefficient" verbs, but this is the windows driver querying ever register so that it can avoid unnecessary writes. The verb list also seems to do everything twice, which was unnecessary in getting this all working. This seems to work about as well as running the verbs script by hand, meaning that it doesn't work perfectly. The left speaker is still slightly louder than the right. I experimented a bit with the verb list from @EverardNisse as well, but I could never get them to work. Interestingly, their verb list contains data for two additional amps at 0x003c and 0x003d. It also seems to occasionally write a small amount of data to each amp I'm not sure what any of this is for either, and the data is completely opaque to me. I'm including the patch file and my analysis of both verb dumps. It would be great to get another set of verbs that fully gets audio working. Going to try and pull my own verb list later if I have time. |
and others
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
Branch name and commit hash of the 2 repositories: sof (firmware/topology) and linux (kernel driver).
Name of the topology file:
Topology: ABI 3:22:1 Kernel ABI 3:21:0 (dmesg output)
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
The text was updated successfully, but these errors were encountered: