Bug 212041
Summary: | LG Gram (2021 Tiger Lake) No sound internel speaker | ||
---|---|---|---|
Product: | Drivers | Reporter: | Nelson Jeppesen (linux) |
Component: | Sound(ALSA) | Assignee: | Jaroslav Kysela (perex) |
Status: | NEW --- | ||
Severity: | normal | CC: | edoubrayrie, eric, jsauer, mail6543210, mangoo, MilesBHuff, parth.mehrotra.cs, ryanmag218, tiwai, wmingcen |
Priority: | P1 | ||
Hardware: | Intel | ||
OS: | Linux | ||
Kernel Version: | 5.11.1 | Subsystem: | |
Regression: | No | Bisected commit-id: | |
Attachments: |
alsa-info.sh` output
My `alsa-info.sh` output |
Description
Nelson Jeppesen
2021-03-03 20:47:02 UTC
It's rather the lack of amp initialization, and it's pretty much vendor-specific. You have to figure out it by yourself via trial-and-error (or try asking the vendor). At first, I'd try different model option values. I have exactly the same issue on my 16" LG Gram 2021 laptop (16Z90PE) (11th gen tiger lake). My distro is Arch (kernel 5.11.7-arch1-1). Before installing "sof-firmware",the sound card wasn't recognized. After installing it, the sound card does be recognized, but there is no sound from the internal speaker when playing audio files or running `speaker-test`, even if the speaker volume bar in KDE Audio Volume bounces as if there was sound coming out. The internal microphone, headphones, and HDMI output all work fine. Created attachment 295953 [details]
My `alsa-info.sh` output
Other people encounter this problem as well. https://superuser.com/questions/1627065/ubuntu-20-04-lts-no-sound-on-lg-gram-2021-a-lot-of-troubleshooting-attempted I've installed Windows on second SSD and rebooted into linux - for some laptops this starts the audio, not the case here I played around around jack remapping, mostly guessing but without luck, as well as random hda-verb commands I'm still reading about how this sound system works but I'm struggling to figure out a way to determine the correct way to troubleshoot this issue I saw a different bug report about using qemu to log hda-verbs, but I've not had time to dig into this, yet (In reply to Mingcen Wei from comment #4) > Other people encounter this problem as well. > > https://superuser.com/questions/1627065/ubuntu-20-04-lts-no-sound-on-lg-gram- > 2021-a-lot-of-troubleshooting-attempted Thank you for adding this here (it is my post). Someone brought this bug report to my attention so I will be on the lookout for workarounds/bug fixes. I will post anything that solves the issue on the thread so others can find it easier. Encountering this as well, happy to provide debugging info. Looks like it could be a more general problem? Similar deal with the new HP Spectre Bug 196147 / Bug 210633. Found this while generally searching for Tiger Lake issues: https://bugzilla.kernel.org/buglist.cgi?quicksearch=tiger" Also no sound on LG Gram 17Z90R (17 inch from year 2023, 13th Gen Intel(R) Core(TM) i7-1360P). Same issue with LG Gram 17Z90R-A.ADB9U1 tested with debian 6.1.0-9 and torvalds/linux.git 6.4.0-rc4 with same result, no sound from internal speakers but sound from headphones is working. echo 1 | sudo tee /sys/module/snd_hda_codec/parameters/dump_coef cat /proc/asound/card0/codec#0 >dump_coef.txt I've dumped HDA verbs on Windows with RtHDDump_V236.zip and compared with Linux. On Linux, dumped HDA verbs are the same booting cold or booting warm after using Windows. The internal speakers don't remain initialized after using Windows and restarting into Linux. I've made first try attempt at bash script to adjusts the verbs to blindly match Windows without success enabling the internal speakers. function Coeff() { sudo hda-verb /dev/snd/hwC0D0 0x20 SET_COEF_INDEX $1; sudo hda-verb /dev/snd/hwC0D0 0x20 SET_PROC_COEF $2; } Coeff 0x03 0x0042 Coeff 0x05 0x2be0 Coeff 0x08 0x0fcf Coeff 0x0f 0x0062 Coeff 0x10 0x1ba1 Coeff 0x22 0x0039 Coeff 0x23 0x23ff Coeff 0x25 0x0001 Coeff 0x26 0xb001 Coeff 0x28 0x0042 Coeff 0x29 0x0800 Coeff 0x2a 0x0d80 Coeff 0x2b 0x0cd0 Coeff 0x2e 0x0252 Coeff 0x31 0x4000 Coeff 0x51 0xa03f Coeff 0x55 0xc301 Coeff 0x5b 0x4301 Coeff 0x7f 0xf1c8 Coeff 0x86 0x000f sudo hda-verb /dev/snd/hwC0D0 0x21 SET_CONNECT_SEL 1 sudo hda-verb /dev/snd/hwC0D0 0x23 SET_CONNECT_SEL 2 I will probably investigate more in the future. I've tried kernels 6.4.2 and 6.5-rc1 (on 17Z90R-G.AD7BY) - still no sound from internal speakers. @eric Were you able to make any more progress with hda-verb? (In reply to Tomasz Chmielewski from comment #10) > @eric Were you able to make any more progress with hda-verb? @Tomasz, sorry no progress. I'll update this thread and publish a solution if I ever find one. Next step would be: https://github.com/ryanprescott/realtek-verb-tools/wiki/How-to-sniff-verbs-from-a-Windows-sound-driver My machine (2023 LG Gram 16 2-in-1 notebook, "16T90R-K.ADB9U1 Type1Version", core i7-1360p) has identical built-in speaker issue as listed in this ticket... 3.5mm headset audio works fine. As was suggested for a next step on this ticket, I carefully followed the steps listed at: https://github.com/ryanprescott/realtek-verb-tools/wiki/How-to-sniff-verbs-from-a-Windows-sound-driver Used a Win11 VM, passed the audio device through, installed the Windows sound driver in the VM... and was able to hear sound from the Win11 VM on my 2023 LG Gram 16 2-in-1 laptop. So that was good news. The VM was generating sound to the pass-through audio device and to the built-in speakers. However, I was unable to capture any CORB buffer dumps from qemu... and hence was not able to capture any hda verbs that the VM was using to initialize the speakers. I do see vfio_region_writes being captured: vfio_region_write (0000:00:1f.3:region0+0x38, 0x0, 4) vfio_region_write (0000:00:1f.3:region0+0x804, 0x40000000, 4) vfio_region_write (0000:00:1f.3:region0+0x804, 0xc0000000, 4) vfio_region_write (0000:00:1f.3:region0+0x20, 0x80000000, 4) vfio_region_write (0000:00:1f.3:region0+0x20, 0xc0000000, 4) vfio_region_write (0000:00:1f.3:region0+0x804, 0xc0000000, 4) vfio_region_write (0000:00:1f.3:region0+0x92, 0x11, 2) vfio_region_write (0000:00:1f.3:region0+0x804, 0xc0000001, 4) vfio_region_write (0000:00:1f.3:region0+0x98, 0x2b1fe000, 4) vfio_region_write (0000:00:1f.3:region0+0x9c, 0x1, 4) but nothing that the realtek verb tools or that QemuHDADump will recognize or do anything with. The QemuHDADump utility also had these steps listed, very similar to the link used above: https://github.com/Conmanx360/QemuHDADump/wiki/Setup-and-usage-of-the-program Any thoughts? OK, I was able to get sound working! I had to modify qemu to capture the hda-verb info being sent from the Win11 VM. Only one file (hw/vfio/common.c) needs to be modified. Once that was done, used the realtek verb tools to narrow down the captured verbs to the verbs needed to initialize the speakers (basically, the first 2380 verbs captured). I guess it could be narrowed down even more? For now, as part of my login script, I simply use the realtek verb tools to apply the verbs. I've created a public repo to hold my scripts, steps, etc. at: https://github.com/jeffsauer/lggram2023speakerfix Regards. I confirm #13 fixes the issue for me as well, immediately, on the exact same model as Jeff. (Thanks!) For some reason, it is not the same verbs as on some other non-convertible 2023 models despite identical specs. Those seems to accept another set of patches by joshuagrisham, according to https://forums.fedoraforum.org/showthread.php?331130-Fixing-ALC298-audio (*maybe* related to Bug 207423 and fixed upstream with the alc298-samsung-amp patch) To be clear: 16T90R-K.ADB9U1 -> Jeff's verbs 17Z90R-K.ADS9U1 -> joshuagrisham's verbs 16Z90R-A -> joshuagrisham's verbs ...to be confirmed -- my intuition would be that the difference would nvidia (...-K) vs intel-only (...-A) but it does match the 2nd report. I'm not an expert but I think what could help is if people with various models (eg Tomasz and Eric from #8 and #9), can try the following instructions and report which ones work and their model variant (sudo dmidecode -s system-product-name). (1) Jeff's verbs above -- I have repackaged them to simplify the procedure: sudo apt install -y alsa-tools wget https://gist.githubusercontent.com/eddy-geek/ef86267fbec87479aba905302909921a/raw/ -O necessary-verbs.sh chmod +x necessary-verbs.sh sudo ./necessary-verbs.sh (should work immediately but not survive reboots) (2) joshua's verbs for samsung sudo apt install -y alsa-tools wget https://github.com/joshuagrisham/galaxy-book2-pro-linux/raw/main/sound/necessary-verbs.sh chmod +x necessary-verbs.sh sudo ./necessary-verbs.sh (should work immediately but not survive reboots) (3) and alternatively, the upstream fix for samsung: sudo tee /etc/modprobe.d/audio-fix-alc298--samsung-headphone.conf <<< 'options snd-hda-intel model=alc298-samsung-amp' (should work permanently after after reboot) https://raw.githubusercontent.com/joshuagrisham/galaxy-book2-pro-linux/main/sound/necessary-verbs.sh - this one fixed the issue for me, thanks! I'm running 17Z90R-G.AD7BY, it is intel-only, no nvidia. I can confirm that for LG Gram 17Z90R-A.ADB9U1 (2) joshuagrisham verbs works. Thanks! edoubrayrie, I have a 17Z90R-K.ADS9U1, but it actually does not have NVIDIA -- so I don't think that's what "-K" means. As well: Neither joshuagrisham's verbs nor Jeff's verbs seem to be working for me; and the same for `options snd-hda-intel model=alc298-samsung-amp`. :\ I got it to work with joshuagrisham's verbs! It turns out my issue was that, even though I had `sof-firmware` installed and loaded, the requisite SOF module was not actually being used. I needed to create `/etc/modprobe.d/sof.conf`, and add `options snd slots=snd_soc_skl_hda_dsp` to it. I also, for good measure, added `snd-hda-intel` to `/etc/modprobe.d/blacklist.conf`. (Tips found at https://forum.manjaro.org/t/howto-set-up-the-audio-card-in-samsung-galaxy-book/37090) |