[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! |
|
Regarding "how an EQ tool could work" my take is that it could just send the EQ coef values using some kind of DMA / HDA verb interface (e.g. with the "Easy path" is just using I think the bigger job will be actually figuring out what all of the payloads need to be -- when I tried to analyze them I did not see anything obvious with how they seem to correlate to frequency ranges or similar... |
Hi! I've been following this thread from the beginning, and the one of the original list of verbs fixed my issue, and just been running it by hand when needed ever since. Now that it sounds like, all these years later :), we are finally getting to a kernel patch thanks to all your great work - I just wanted to make sure that my model will be included. I just looked it up, and it is "950XEE". It's a Samsung Galaxy Book2 Pro.. I think it's basically the same as NP950XED for all intents and purposes, its just the model that came with Intel Arc Graphics and 32gb (I bought it cause it was the only one with 32gbs available back then). Is it possible to include my model in the patch? |
|
Hi @drewdrew0 , thanks for speaking up -- not sure if your device is covered or not! There is already a patch submitted and applied to the sound tree but it is not a big deal to make another one and send it in. Not sure when the cut-off for 6.11 will be but hopefully there is still some time! (and if not then 6.12 will be right around the corner anyway) What is the value you see if you run |
Thanks @joshuagrisham ! So the value returned by the above command is: |
|
@crinavar and @scolton99 - Thanks for confirming those verbs work for you. I'm making a kernel patch for the Razer Blade HDA fixups, can you confirm your subsystem ID? You can On a RZ09-0483 I've got |
RZ09-0484, I've got |
|
hi @j-m-harris Currently, the old verbs list fix requires me to also close and open lid and then audio wakes up. I have Arch Linux up to date. |
Thanks @drewdrew0 patch submitted, you can see it here: https://lore.kernel.org/linux-sound/20240913080055.10807-1-josh@joshuagrisham.com/T/#u 😎 |
|
Hi @j-m-harris I took a quick look at the verbs list that was linked and can see that there is a lot of extra stuff in that list as well that I am almost 100% certain is not necessary. I think it would be good to do a similar analysis as I did for the Samsung devices like here: #4055 (comment) I can try to start taking a look at the verbs file but I suspect it will be a bit hard to tell exactly since it is already a "cleaned" file, it would be better to have an even more raw file and even better one that comes out from my own QEMU patch and cleanup script (info about that in the comment I linked above). From a quick check of your verbs list I can see that it is REALLY similar as far as HOW it works but that the actual coef values are a bit different. So it would not work to just "add" your devices but it might make sense to re-factor a bit so that even your Razor devices work with the same fixups that I created (just need a bit more ability to control the speaker amp IDs and payloads per device instead of hard-coding them like I have done) |
Adds support for GB2Pro Arc variant (NP950XEE) based on successful test and information provided by Github user drewdrew0 [1]. [1]: thesofproject#4055 (comment) Signed-off-by: Joshua Grisham <josh@joshuagrisham.com> Link: https://patch.msgid.link/20240913080055.10807-1-josh@joshuagrisham.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
Hi @joshuagrisham, I own a Razer Blade 14 (2023 model), and I'm following this discussion with great interest. Given the ongoing refinement of the verbs list and the proposed approach to make the solution more adaptable to different devices, I'm curious to know if these updates will benefit my Razer Blade 14 as well. Understanding that there's a suggestion to refactor the approach to better control speaker amp IDs and payloads per device, I'm hopeful that this will make the new solution more universally applicable, including for newer models like mine. Could you provide some insights into whether the changes discussed here will extend support to the Razer Blade 14 (2023 model) and what steps might be involved to ensure compatibility? Thank you for all the hard work! Best, |
|
Hi @KeyStrokeVII, I noticed that @j-m-harris had uploaded a CORB event log that might be able to help here: #4055 (comment) but without timestamps on when the actual values were read/written it is a bit hard to understand the "context" for each event (e.g. startup and driver init stuff usually happens within the first few seconds, then there is a gap, a few seconds later maybe some kind of Windows startup/login sound happens, eventually shutdown also happens all together within the last few seconds) Also I feel like maybe there was some kind of a "lag" or other issue when tracing the events, and that the log is actually missing some lines of what really happened ... e.g. just as example I am almost 100% certain that before line 3175 in the file (id 0x0030d0) there should have been a AC_VERB_SET_COEF_INDEX event that is missing in the log (write 0x23 to node 0x20 verb 0x500) but there is no line in the log that does this. That is just one example but there are several others that I found where I am left scratching my head and having trouble making 100% sense of this log, unfortunately! I also would kind of like to know what the coef reads returned (e.g. line 106 and 108 in the file I would really like to know what the value returned was .. I suspect even here or somewhere near here were also some "lost" events?) What I think I have been able to tell so far is that the device seems to have 2 speaker amps with id 0x10 and 0x12 respectively (instead of 4 like some of the ones discussed in this thread) but even that seems weird since the specs for this device I found online say that there are 4 total speakers on this device. If I were to look at it further then what I would really personally want is if someone could run something more like my modified version of QEMU (see patch here: https://github.com/joshuagrisham/galaxy-book2-pro-linux/blob/main/sound/qemu/vfio-common.patch though might need to insert the changes manually into common.c to work for other versions of QEMU source if you don't use exactly the same commit I generated my patch file from... plus, the parsing script here: https://github.com/joshuagrisham/galaxy-book2-pro-linux/blob/main/sound/qemu/hda-verb-log-to-csv.py ) and then ideally that whomever tested and captured the trace could do it a bit like this:
(Ideally you would actually disable all notification sounds and startup/login/shutdown sounds in the Windows VM as a pre-prep step, then shut it off, before doing this test so that NOTHING is played until you manually play some audio yourself at a controlled time -- this is how I did it on my device! This is especially helpful for these devices which seem to be sending tons of app-specific EQ settings baked into the driver so there are hundreds of extra events if there is a lot of audio playing at random times, and it makes it harder to figure out the basic minimum that is actually needed) Plus it would be good to have an RtHDDump.exe output from the same device in a "real" Windows environment with at least two scenarios: without playing any audio (and no audio has been playing for at least 30 seconds), and while audio is playing back. The above "time log", plus RtHDDump files, and the trace/csv files from a QEMU with my patch would be a really good start IMHO to take some really good steps towards being able to identify exactly which events are doing exactly what. 😺 |
|
@joshuagrisham Well done! Congrats on getting the patch in! 6.11 is going to get a lot of people's audio working without any workaround scripts. I just want to add - the windows driver has files pertaining to the following hw ids Not sure if it's worth pre-emptively adding these into the kernel since they would not have been tested though. Just figured I'd mention it in case any more info comes out that might allow them to be added |
|
This is a good idea @hamfirst but the weird thing is that this list seems to be missing some subsystem IDs (for example mine is not even in the list!). Then I thought that maybe it only has the ones which have 4 speaker amps, but even that was not the same.. on first glance, it feels a bit random? I was thinking it would actually be nice to really figure out how it might be possible to interrogate the device / read some values from it and just use something like a TBH the existing quirk |
Thanks again @joshuagrisham :) I will be really happy when 6.12 rolls around and no more workaround scripts. In the meantime, one last question ;) ? Do you know what is the new, current list of verbs for my machine (NP950XEE)? I am still using one of the original ones from this thread so long ago, that 75% of the time leaves one speaker softer, and has some distortion at higher volumes, etc. I've seen a lot of activity lately on this thread, and know you've done a lot of hard work on the verb list, so wanna just make sure I'm using the latest and best in the meantime. Thanks again! |
|
@joshuagrisham That is some pretty impressive analysis, I agree it would be preferable to get the verb list down to what is absolutely required. @KeyStrokeVII Is your Razer Blade 14 the 2023 model, RZ09-0482? If so I expect the subsystem ID is |
Yes its RZ09-0482x |
|
Hi, thank you both for this amazing work. (1) can you confirm the new patches in 6.11 will be testable on any other model with something like: (option found in patch_realtek.c) ? (2) I am the owner of a LG gram 16 2-in-1 16T90R-K.ADB9U1, subsystem_id I'm still using jeff's verbs as I detailed in c14 on Kernel bug 212041 -- unfortunately joshua's initial verbs were not enough in this case so I'm guessing |
|
I have been following this thread for a long time and Have used @joshuagrisham 's verbs to get working audio. That process is simple but not a permanent fix like the one I am seeing from 6.11. Can someone please point me in the direction of where I can start learning to either build the kernel with this patch in it? Im on Arch currently with my Samsung Pro3 360. I am a Debian user typically but this all seems to be bleeding edge fixing and the rolling releases with Arch will probably have the fix before the rest of the releases. Thanks in advance and I really appreciate everything you all have done to get this moving. (After this is all fixed we can start working on the webcam fix :) |
Hi @eddy-geek yes I think the patch will be testable as you mentioned in (1) (2) I don't think the patch will work with your device as the payloads I see in your script are slightly different. IMHO it would be very interesting to see some traces for your device like I described in that comment you mentioned: #4055 (comment) It might be possible to try and avoid that but a little bit trial-and-error... How many speakers does your device actually have? I am guessing 4 but your capture is a bit odd in that it seems to be acting on 2 different sets of IDs (some things against 0x10-0x13 and some things against 0x38-0x3b). Anyway "just a guess" but here is my guess on what a more minimal set of verbs for your device would look like as gleaned from your capture: #!/bin/sh
# "does something" (disables??) on 0x10
hda-verb /dev/snd/hwC0D0 0x20 0x500 0x22
hda-verb /dev/snd/hwC0D0 0x20 0x400 0x10
hda-verb /dev/snd/hwC0D0 0x20 0x500 0x23
hda-verb /dev/snd/hwC0D0 0x20 0x400 0x7c
hda-verb /dev/snd/hwC0D0 0x20 0x500 0x26
hda-verb /dev/snd/hwC0D0 0x20 0x4b0 0x1a
hda-verb /dev/snd/hwC0D0 0x20 0x500 0x23
hda-verb /dev/snd/hwC0D0 0x20 0x400 0x70
hda-verb /dev/snd/hwC0D0 0x20 0x500 0x26
hda-verb /dev/snd/hwC0D0 0x20 0x4b0 0x1a
# "does something" (disables??) on 0x11
hda-verb /dev/snd/hwC0D0 0x20 0x500 0x22
hda-verb /dev/snd/hwC0D0 0x20 0x400 0x11
hda-verb /dev/snd/hwC0D0 0x20 0x500 0x23
hda-verb /dev/snd/hwC0D0 0x20 0x400 0x7c
hda-verb /dev/snd/hwC0D0 0x20 0x500 0x26
hda-verb /dev/snd/hwC0D0 0x20 0x4b0 0x1a
hda-verb /dev/snd/hwC0D0 0x20 0x500 0x23
hda-verb /dev/snd/hwC0D0 0x20 0x400 0x70
hda-verb /dev/snd/hwC0D0 0x20 0x500 0x26
hda-verb /dev/snd/hwC0D0 0x20 0x4b0 0x1a
# "does something" (disables??) on 0x12
hda-verb /dev/snd/hwC0D0 0x20 0x500 0x22
hda-verb /dev/snd/hwC0D0 0x20 0x400 0x12
hda-verb /dev/snd/hwC0D0 0x20 0x500 0x23
hda-verb /dev/snd/hwC0D0 0x20 0x400 0x7c
hda-verb /dev/snd/hwC0D0 0x20 0x500 0x26
hda-verb /dev/snd/hwC0D0 0x20 0x4b0 0x1a
hda-verb /dev/snd/hwC0D0 0x20 0x500 0x23
hda-verb /dev/snd/hwC0D0 0x20 0x400 0x70
hda-verb /dev/snd/hwC0D0 0x20 0x500 0x26
hda-verb /dev/snd/hwC0D0 0x20 0x4b0 0x1a
# "does something" (disables??) on 0x13
hda-verb /dev/snd/hwC0D0 0x20 0x500 0x22
hda-verb /dev/snd/hwC0D0 0x20 0x400 0x13
hda-verb /dev/snd/hwC0D0 0x20 0x500 0x23
hda-verb /dev/snd/hwC0D0 0x20 0x400 0x7c
hda-verb /dev/snd/hwC0D0 0x20 0x500 0x26
hda-verb /dev/snd/hwC0D0 0x20 0x4b0 0x1a
hda-verb /dev/snd/hwC0D0 0x20 0x500 0x23
hda-verb /dev/snd/hwC0D0 0x20 0x400 0x70
hda-verb /dev/snd/hwC0D0 0x20 0x500 0x26
hda-verb /dev/snd/hwC0D0 0x20 0x4b0 0x1a
# "does something" (inits??) on 0x38
hda-verb /dev/snd/hwC0D0 0x20 0x500 0x22
hda-verb /dev/snd/hwC0D0 0x20 0x400 0x38
hda-verb /dev/snd/hwC0D0 0x20 0x500 0x23
hda-verb /dev/snd/hwC0D0 0x20 0x400 0x7c
hda-verb /dev/snd/hwC0D0 0x20 0x500 0x26
hda-verb /dev/snd/hwC0D0 0x20 0x4b0 0x1b
# "does something" (inits??) on 0x39
hda-verb /dev/snd/hwC0D0 0x20 0x500 0x22
hda-verb /dev/snd/hwC0D0 0x20 0x400 0x39
hda-verb /dev/snd/hwC0D0 0x20 0x500 0x23
hda-verb /dev/snd/hwC0D0 0x20 0x400 0x7c
hda-verb /dev/snd/hwC0D0 0x20 0x500 0x26
hda-verb /dev/snd/hwC0D0 0x20 0x4b0 0x1b
# "does something" (inits??) on 0x3a
hda-verb /dev/snd/hwC0D0 0x20 0x500 0x22
hda-verb /dev/snd/hwC0D0 0x20 0x400 0x3a
hda-verb /dev/snd/hwC0D0 0x20 0x500 0x23
hda-verb /dev/snd/hwC0D0 0x20 0x400 0x7c
hda-verb /dev/snd/hwC0D0 0x20 0x500 0x26
hda-verb /dev/snd/hwC0D0 0x20 0x4b0 0x1b
# "does something" (inits??) on 0x3b
hda-verb /dev/snd/hwC0D0 0x20 0x500 0x22
hda-verb /dev/snd/hwC0D0 0x20 0x400 0x3b
hda-verb /dev/snd/hwC0D0 0x20 0x500 0x23
hda-verb /dev/snd/hwC0D0 0x20 0x400 0x7c
hda-verb /dev/snd/hwC0D0 0x20 0x500 0x26
hda-verb /dev/snd/hwC0D0 0x20 0x4b0 0x1b
# "does something" (enables??) on 0x10
hda-verb /dev/snd/hwC0D0 0x20 0x500 0x22
hda-verb /dev/snd/hwC0D0 0x20 0x400 0x10
hda-verb /dev/snd/hwC0D0 0x20 0x500 0x23
hda-verb /dev/snd/hwC0D0 0x20 0x4f0 0x10
# TODO: is setting 0x89 to 0 actually necessary??
hda-verb /dev/snd/hwC0D0 0x20 0x500 0x89
hda-verb /dev/snd/hwC0D0 0x20 0x400 0x0
hda-verb /dev/snd/hwC0D0 0x20 0x500 0x26
hda-verb /dev/snd/hwC0D0 0x20 0x4b0 0x3b
# What is this for on 0x10?? (none of the others have this with 0x23 = 0xf012)
hda-verb /dev/snd/hwC0D0 0x20 0x500 0x23
hda-verb /dev/snd/hwC0D0 0x20 0x4f0 0x12
hda-verb /dev/snd/hwC0D0 0x20 0x500 0x89
hda-verb /dev/snd/hwC0D0 0x20 0x400 0x0
hda-verb /dev/snd/hwC0D0 0x20 0x500 0x26
hda-verb /dev/snd/hwC0D0 0x20 0x4b0 0x3b
# "does something" (enables??) on 0x11
hda-verb /dev/snd/hwC0D0 0x20 0x500 0x22
hda-verb /dev/snd/hwC0D0 0x20 0x400 0x11
hda-verb /dev/snd/hwC0D0 0x20 0x500 0x23
hda-verb /dev/snd/hwC0D0 0x20 0x4f0 0x10
# TODO: is setting 0x89 to 0 actually necessary??
hda-verb /dev/snd/hwC0D0 0x20 0x500 0x89
hda-verb /dev/snd/hwC0D0 0x20 0x400 0x0
hda-verb /dev/snd/hwC0D0 0x20 0x500 0x26
hda-verb /dev/snd/hwC0D0 0x20 0x4b0 0x3b
# "does something" (enables??) on 0x12
hda-verb /dev/snd/hwC0D0 0x20 0x500 0x22
hda-verb /dev/snd/hwC0D0 0x20 0x400 0x12
hda-verb /dev/snd/hwC0D0 0x20 0x500 0x23
hda-verb /dev/snd/hwC0D0 0x20 0x4f0 0x10
# TODO: is setting 0x89 to 0 actually necessary??
hda-verb /dev/snd/hwC0D0 0x20 0x500 0x89
hda-verb /dev/snd/hwC0D0 0x20 0x400 0x0
hda-verb /dev/snd/hwC0D0 0x20 0x500 0x26
hda-verb /dev/snd/hwC0D0 0x20 0x4b0 0x3b
# "does something" (enables??) on 0x13
hda-verb /dev/snd/hwC0D0 0x20 0x500 0x22
hda-verb /dev/snd/hwC0D0 0x20 0x400 0x13
hda-verb /dev/snd/hwC0D0 0x20 0x500 0x23
hda-verb /dev/snd/hwC0D0 0x20 0x4f0 0x10
# TODO: is setting 0x89 to 0 actually necessary??
hda-verb /dev/snd/hwC0D0 0x20 0x500 0x89
hda-verb /dev/snd/hwC0D0 0x20 0x400 0x0
hda-verb /dev/snd/hwC0D0 0x20 0x500 0x26
hda-verb /dev/snd/hwC0D0 0x20 0x4b0 0x3bIt would be interesting to see if you disable your service/scripts and power off, then power back on and run this.. does it work? And also if you repeat that but only run parts of it (e.g. just run the 0x38-0x3b parts vs just run the 0x10-0x13 parts) .. does it work then and/or any difference? |
|
Hi @nottoosmart if you are just looking to try and fetch + make + install the very latest sound tree (the git clone --branch for-next --depth 1 git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git linux-sound-for-next
cd linux-sound-for-next
cp /boot/config-`uname -r`* .config
make olddefconfig
make -j `nproc --all` all # make all using all CPUs
sudo make modules_install
sudo make installThen of course you would need to reboot and choose this new kernel using your boot selector :) Note if your existing boot config (the one being copied from in the above) contains certificate-based module signing then you might need to disable this in the config or find and copy over the certificates etc as per the paths given in your config; one example I have given before for Debian-based distros can be seen here: https://github.com/joshuagrisham/samsung-galaxybook-extras/tree/main/driver#how-to-avoid-signature-andor-required-key-missing Also sometimes the latest branch can have bugs that won't compile or work right--just need to be aware of that and possible try a more "stable" version (either use Torvald's mainline branch or point to a different tag or branch with the My own tweaks to that (removing the EQ payloads so you get a little less "muddy" sound, plus potentially better battery life due to disabling the speaker amps when not in use) will come first with 6.12 when it releases in the coming weeks, so if you want to try it now then you will have to build and install it yourself, or wait until 6.12 and try it then. :) |
|
@joshuagrisham you seem to know a lot about the innards of this, so I was hoping you could help with the following. I've been reducing the verbs down for the Razer hardware, and in addition refactoring the kernel patch to use the WRITE_COEF structure (as directed to by Takashi Iwai, kernel bugzilla #207423). As I understand it, WRITE_COEF always sets a single pair of coefficient index and value. However on the razer dump there are some sets of verbs with multiple coefficient values like: .. and as far as my testing has shown, it really does require all those values to be written in that order. Can you give me some guidance on how those can be represented while using WRITE_COEF, or some insight into why this might be the case? |
|
Hi @j-m-harris Based on that information, I think the snippet you showed would do the following: But I also would guess that the second and last lines are wrong, and instead should look like this: (though after a quick glance at hda-verb.c my guess it is will probably work like you wrote as well) Also what I have seen in most of these traces (including my original) is that they are getting destroyed a bit unfortunately through various "clean up" scripts that can be found online in various tutorials (where originally those devices seemed to be much more simple and less "chatty" than the new ones we are looking at here), so it becomes kind of hard to tell what is actually happening and there could be cases where important values are being removed. This is actually why I removed my original necessary-verbs.sh script in my repository (found references to it in lots of places including askubuntu, Manjaro forums, Arch forums, etc etc 😆 ) and replaced it with essentially my findings posted in comments above, and why I made the recommendations above to actually get a new set of traces which do not remove the data but instead reformat them and make all of the data available in CSV to make it a bit easier to filter and analyze (and hopefully not miss anything 😇 ) |
|
Thank you for the pointers @joshuagrisham ! I didn't know that writing the coefficient value incremented the index, that's cleared it right up for me. Cheers. |
[ Upstream commit 7e4d4b3 ] I have done a lot of analysis for these type of devices and collaborated quite a bit with Nick Weihs (author of the first patch submitted for this including adding samsung_helper.c). More information can be found in the issue on Github [1] including additional rationale and testing. The existing implementation includes a large number of equalizer coef values that are not necessary to actually init and enable the speaker amps, as well as create a somewhat worse sound profile. Users have reported "muffled" or "muddy" sound; more information about this including my analysis of the differences can be found in the linked Github issue. This patch refactors the "v2" version of ALC298_FIXUP_SAMSUNG_AMP to a much simpler implementation which removes the new samsung_helper.c, reuses more of the existing patch_realtek.c, and sends significantly fewer unnecessary coef values (including removing all of these EQ-specific coef values). A pcm_playback_hook is used to dynamically enable and disable the speaker amps only when there will be audio playback; this is to match the behavior of how the driver for these devices is working in Windows, and is suspected but not yet tested or confirmed to help with power consumption. Support for models with 2 speaker amps vs 4 speaker amps is controlled by a specific quirk name for both types. A new int num_speaker_amps has been added to alc_spec so that the hooks can know how many speaker amps to enable or disable. This design was chosen to limit the number of places that subsystem ids will need to be maintained: like this, they can be maintained only once in the quirk table and there will not be another separate list of subsystem ids to maintain elsewhere in the code. Also updated the quirk name from ALC298_FIXUP_SAMSUNG_AMP2 to ALC298_FIXUP_SAMSUNG_AMP_V2_.. as this is not a quirk for "Amp #2" on ALC298 but is instead a different version of how to handle it. More devices have been added (see Github issue for testing confirmation), as well as a small cleanup to existing names. [1]: thesofproject/linux#4055 (comment) Signed-off-by: Joshua Grisham <josh@joshuagrisham.com> Link: https://patch.msgid.link/20240909193000.838815-1-josh@joshuagrisham.com Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 7e4d4b3 ] I have done a lot of analysis for these type of devices and collaborated quite a bit with Nick Weihs (author of the first patch submitted for this including adding samsung_helper.c). More information can be found in the issue on Github [1] including additional rationale and testing. The existing implementation includes a large number of equalizer coef values that are not necessary to actually init and enable the speaker amps, as well as create a somewhat worse sound profile. Users have reported "muffled" or "muddy" sound; more information about this including my analysis of the differences can be found in the linked Github issue. This patch refactors the "v2" version of ALC298_FIXUP_SAMSUNG_AMP to a much simpler implementation which removes the new samsung_helper.c, reuses more of the existing patch_realtek.c, and sends significantly fewer unnecessary coef values (including removing all of these EQ-specific coef values). A pcm_playback_hook is used to dynamically enable and disable the speaker amps only when there will be audio playback; this is to match the behavior of how the driver for these devices is working in Windows, and is suspected but not yet tested or confirmed to help with power consumption. Support for models with 2 speaker amps vs 4 speaker amps is controlled by a specific quirk name for both types. A new int num_speaker_amps has been added to alc_spec so that the hooks can know how many speaker amps to enable or disable. This design was chosen to limit the number of places that subsystem ids will need to be maintained: like this, they can be maintained only once in the quirk table and there will not be another separate list of subsystem ids to maintain elsewhere in the code. Also updated the quirk name from ALC298_FIXUP_SAMSUNG_AMP2 to ALC298_FIXUP_SAMSUNG_AMP_V2_.. as this is not a quirk for "Amp #2" on ALC298 but is instead a different version of how to handle it. More devices have been added (see Github issue for testing confirmation), as well as a small cleanup to existing names. [1]: thesofproject/linux#4055 (comment) Signed-off-by: Joshua Grisham <josh@joshuagrisham.com> Link: https://patch.msgid.link/20240909193000.838815-1-josh@joshuagrisham.com Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 7e4d4b3 ] I have done a lot of analysis for these type of devices and collaborated quite a bit with Nick Weihs (author of the first patch submitted for this including adding samsung_helper.c). More information can be found in the issue on Github [1] including additional rationale and testing. The existing implementation includes a large number of equalizer coef values that are not necessary to actually init and enable the speaker amps, as well as create a somewhat worse sound profile. Users have reported "muffled" or "muddy" sound; more information about this including my analysis of the differences can be found in the linked Github issue. This patch refactors the "v2" version of ALC298_FIXUP_SAMSUNG_AMP to a much simpler implementation which removes the new samsung_helper.c, reuses more of the existing patch_realtek.c, and sends significantly fewer unnecessary coef values (including removing all of these EQ-specific coef values). A pcm_playback_hook is used to dynamically enable and disable the speaker amps only when there will be audio playback; this is to match the behavior of how the driver for these devices is working in Windows, and is suspected but not yet tested or confirmed to help with power consumption. Support for models with 2 speaker amps vs 4 speaker amps is controlled by a specific quirk name for both types. A new int num_speaker_amps has been added to alc_spec so that the hooks can know how many speaker amps to enable or disable. This design was chosen to limit the number of places that subsystem ids will need to be maintained: like this, they can be maintained only once in the quirk table and there will not be another separate list of subsystem ids to maintain elsewhere in the code. Also updated the quirk name from ALC298_FIXUP_SAMSUNG_AMP2 to ALC298_FIXUP_SAMSUNG_AMP_V2_.. as this is not a quirk for "Amp #2" on ALC298 but is instead a different version of how to handle it. More devices have been added (see Github issue for testing confirmation), as well as a small cleanup to existing names. [1]: thesofproject/linux#4055 (comment) Signed-off-by: Joshua Grisham <josh@joshuagrisham.com> Link: https://patch.msgid.link/20240909193000.838815-1-josh@joshuagrisham.com Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 7e4d4b3 ] I have done a lot of analysis for these type of devices and collaborated quite a bit with Nick Weihs (author of the first patch submitted for this including adding samsung_helper.c). More information can be found in the issue on Github [1] including additional rationale and testing. The existing implementation includes a large number of equalizer coef values that are not necessary to actually init and enable the speaker amps, as well as create a somewhat worse sound profile. Users have reported "muffled" or "muddy" sound; more information about this including my analysis of the differences can be found in the linked Github issue. This patch refactors the "v2" version of ALC298_FIXUP_SAMSUNG_AMP to a much simpler implementation which removes the new samsung_helper.c, reuses more of the existing patch_realtek.c, and sends significantly fewer unnecessary coef values (including removing all of these EQ-specific coef values). A pcm_playback_hook is used to dynamically enable and disable the speaker amps only when there will be audio playback; this is to match the behavior of how the driver for these devices is working in Windows, and is suspected but not yet tested or confirmed to help with power consumption. Support for models with 2 speaker amps vs 4 speaker amps is controlled by a specific quirk name for both types. A new int num_speaker_amps has been added to alc_spec so that the hooks can know how many speaker amps to enable or disable. This design was chosen to limit the number of places that subsystem ids will need to be maintained: like this, they can be maintained only once in the quirk table and there will not be another separate list of subsystem ids to maintain elsewhere in the code. Also updated the quirk name from ALC298_FIXUP_SAMSUNG_AMP2 to ALC298_FIXUP_SAMSUNG_AMP_V2_.. as this is not a quirk for "Amp #2" on ALC298 but is instead a different version of how to handle it. More devices have been added (see Github issue for testing confirmation), as well as a small cleanup to existing names. [1]: thesofproject#4055 (comment) Signed-off-by: Joshua Grisham <josh@joshuagrisham.com> Link: https://patch.msgid.link/20240909193000.838815-1-josh@joshuagrisham.com Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 7e4d4b3 ] I have done a lot of analysis for these type of devices and collaborated quite a bit with Nick Weihs (author of the first patch submitted for this including adding samsung_helper.c). More information can be found in the issue on Github [1] including additional rationale and testing. The existing implementation includes a large number of equalizer coef values that are not necessary to actually init and enable the speaker amps, as well as create a somewhat worse sound profile. Users have reported "muffled" or "muddy" sound; more information about this including my analysis of the differences can be found in the linked Github issue. This patch refactors the "v2" version of ALC298_FIXUP_SAMSUNG_AMP to a much simpler implementation which removes the new samsung_helper.c, reuses more of the existing patch_realtek.c, and sends significantly fewer unnecessary coef values (including removing all of these EQ-specific coef values). A pcm_playback_hook is used to dynamically enable and disable the speaker amps only when there will be audio playback; this is to match the behavior of how the driver for these devices is working in Windows, and is suspected but not yet tested or confirmed to help with power consumption. Support for models with 2 speaker amps vs 4 speaker amps is controlled by a specific quirk name for both types. A new int num_speaker_amps has been added to alc_spec so that the hooks can know how many speaker amps to enable or disable. This design was chosen to limit the number of places that subsystem ids will need to be maintained: like this, they can be maintained only once in the quirk table and there will not be another separate list of subsystem ids to maintain elsewhere in the code. Also updated the quirk name from ALC298_FIXUP_SAMSUNG_AMP2 to ALC298_FIXUP_SAMSUNG_AMP_V2_.. as this is not a quirk for "Amp #2" on ALC298 but is instead a different version of how to handle it. More devices have been added (see Github issue for testing confirmation), as well as a small cleanup to existing names. [1]: thesofproject/linux#4055 (comment) Signed-off-by: Joshua Grisham <josh@joshuagrisham.com> Link: https://patch.msgid.link/20240909193000.838815-1-josh@joshuagrisham.com Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
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: