Bug 207423
|
Description
Mike Pozulp
2020-04-24 05:07:52 UTC
Created attachment 288693 [details]
Output from RtHDDump.exe
Created attachment 288695 [details]
Output from RtHDDump.exe with headphones plugged in
The fix for the headphone pin looks good. Care to submit the patch (or ask the original author to do so)? It just lacks Signed-off-by line, but other than that it's OK. And the internal speaker problem: it's often indeed an issue of I2S driven speaker amp. It's with DSP, so either SOF or SST driver would work. Have you tried the latest SOF driver with HD-audio legacy codec support? `lsmod` shows: ``` snd_sof_xtensa_dsp 16384 2 snd_sof_intel_hda_common,snd_sof_intel_byt snd_soc_sst_dsp 40960 1 snd_soc_skl snd_intel_dspcfg 28672 4 snd_hda_intel,snd_sof_pci,snd_sof_intel_hda_common,snd_soc_skl ``` So are these mods not relevant to our situation? Takashi: Submitted. I'll attach it here as well. Ronin: lsmod shows those mods for me as well. Perhaps we need to use a module option, or maybe these aren't the modules which Takashi was referring to. Created attachment 289043 [details]
alc298 headphone fix
Takashi: I'm attaching my lsmod output. Do you see anything wrong? Created attachment 289071 [details]
lsmod output
(In reply to Takashi Iwai from comment #3) > Have you tried the latest SOF driver with HD-audio legacy codec support? Have I? I'm running the 5.6.3 kernel and I have these modules loaded (mapping is module: source code) snd_sof_xtensa_dsp: sound/soc/sof/xtensa/core.c snd_soc_sst_dsp: sound/soc/intel/common/sst-dsp.c snd_intel_dspcfg: sound/hda/intel-dsp-config.c snd_sof_intel_hda: sound/soc/sof/intel/hda-codec.c snd_sof_intel_hda_common: sound/soc/sof/intel/hda.c Is snd_sof_intel_hda the "SOF driver with HD-audio legacy codec support"? Pierre-Louis Bossart authored the commit that created this module on 2019-04-12: 5507b8103e26 (ASoC: SOF: Intel: Add support for HDAudio codecs). I did some other research worth sharing, -CannonLake (CNL) and WhiskeyLake (WHL) are almost the same architecture [1], meaning that while my Samsung's i7-8565U is a WHL SoC, the kernel sometimes has one config which applies to both, like SND_SOC_INTEL_CNL in sound/soc/intel/Kconfig. -SOF is Sound Open Firmware, a Linux Foundation sponsored project from Intel to develop open source DSP firmware [2]. Liam Girdwood, Intel, "Sound Open Firmware" (2018) at 23:46 [3] shows a table of SOF platforms with this row Vendor | Platform | DSP | Status Intel | CannonLake, WhiskeyLake | 4 * Xtensa Hifi4 | Upstream, support for I2S, DMIC, HDMI, and HDA This may explain why my machine and Ronin's machine have snd_sof_xtensa_dsp loaded. Xtensa Hifi 4 is a DSP from Tensilica that they market as an SoC core for audio, voice, and speech processing [4]. The Xtensa Hifi 4 could be the "Quad-Core Audio DSP for high fidelity, low power audio, and multi-voice services supported Wake on Voice" that the i7-8565U press release refers to [5]. The drivers on my Windows partition also refer to Wake on Voice (WoV): /mnt/windows/ProgramData/SAMSUNG/SamsungUpdate3/data/0fc37d78-3143-4c1f-99fd-610096e43a86/Sounddrv/IntelHDASST/WoVartifacts. [1] https://www.quora.com/What-are-the-differences-among-Intel-Core-8th-gen-Coffee-Lake-Whiskey-Lake-Cannon-Lake-and-Cascade-Lake [2] https://www.linuxfoundation.org/press-release/2018/03/the-linux-foundation-welcomes-sound-open-firmware-project [3] https://youtu.be/vwDoEumA1Mo?t=1426 [4] https://ip.cadence.com/ipportfolio/tensilica-ip/audio [5] https://www.intel.com/content/www/us/en/products/docs/processors/core/8th-gen-core-u-and-y-series-brief.html Takashi: I'm attaching my output from running "systool -vm" on each of the modules I listed. A couple have parameters, should we try setting them?
snd_intel_dspcfg
Parameters:
dsp_driver = "0"
snd_sof_intel_hda_common
Parameters:
codec_mask = "-1"
dmic_num = "-1"
use_common_hdmi = "Y"
Here are the descriptions of the parameters from running "modinfo" on the two modules:
parm: dsp_driver:Force the DSP driver for Intel DSP (0=auto, 1=legacy, 2=SST, 3=SOF) (int)
parm: codec_mask:SOF HDA codec mask for probing (int)
parm: dmic_num:SOF HDA DMIC number (int)
parm: use_common_hdmi:SOF HDA use common HDMI codec driver (bool)
Created attachment 289075 [details]
systool -vm output
Maybe yours have no DMIC, hence it binds with the legacy driver. Just to be sure, you can try to load with snd_intel_dspcfg.dsp_driver=3 boot option. Then it will forcibly load with SOF. It might be irrelevant with the original problem, but still it's worth to try. No luck. I rebooted with /etc/modprobe.d/dspdriver.conf options snd_intel_dspcfg dsp_driver=3 and still no speaker sound. After booting I tried running alsa_info.sh and it failed with the message alsactl: save_state:1595: No soundcards found... The DSP may be used to connect speakers, but it's not necessary. There may be some amplifiers connected to the HDA codec which are not initialized by BIOS (thus they are not active in Linux). There are some project to to dump the codec communication for the windows driver using qemu like: https://github.com/Conmanx360/QemuHDADump But it requires a time and skills to extract the right information to add Linux support. The coefficient widgets for some Realtek codecs control also I2C bus integrated to those codecs. So the amplifiers may be controlled through this bus. Jaroslav, when I run qemu the only output I get is
qemu-system-x86_64: vfio: Cannot reset device 0000:00:1f.3, no available reset mechanism.
First, I compiled qemu with tracing enabled (see [1] for full configure line)
./configure \
--enable-trace-backends=log \
--target-list=x86_64-softmmu
Second, I created a Win10 img, downloaded a Win10 iso, then booted qemu and clicked through the Win10 installer
qemu-img create -f qcow2 virtual-machine.img 20G
qemu-system-x86_64 -enable-kvm -hda virtual-machine.img -cdrom Win10_1909_English_x64.iso -m 4G -smp 4
Then I found the PCI group for the HDA controller
00:1f.0 ISA bridge [0601]: Intel Corporation Cannon Point-LP LPC Controller [8086:9d84] (rev 11)
00:1f.3 Multimedia audio controller [0401]: Intel Corporation Cannon Point-LP High Definition Audio Controller [8086:9dc8] (rev 11)
00:1f.4 SMBus [0c05]: Intel Corporation Cannon Point-LP SMBus Controller [8086:9da3] (rev 11)
00:1f.5 Serial bus controller [0c80]: Intel Corporation Cannon Point-LP SPI Controller [8086:9da4] (rev 11)
I set my commandline to (from [2])
GRUB_CMDLINE_LINUX_DEFAULT="text pci-stub.ids=8086:9d84,8086:9dc8,8086:9da3,8086:9da4 iommu=pt intel_iommu=on"
grub-mkconfig -o /boot/grub/grub.cfg
I rebooted my laptop and then created the vfio devices
sudo modprobe pci-stub
sudo modprobe vfio-pci
echo 0000:00:1f.X | sudo tee /sys/bus/pci/devices/0000:00:1f.X/driver/unbind <- for X in {0, 3, 4, 5}
echo 0x8086 0xWXYZ | sudo tee /sys/bus/pci/drivers/vfio-pci/new_id <- for WXYZ in {9d84, 9dc8, 9da3, 9da4}
I booted my Win10 img in qemu
sudo qemu-system-x86_64 \
-M q35 -m 2G -cpu host,kvm=off \
-enable-kvm \
-device vfio-pci,host=00:1f.3,multifunction=on,x-no-mmap \
-hda virtual-machine.img \
-trace events=events.txt
where events.txt contained
-vfio_region_read
vfio_region_write
The only output in the terminal is the "Cannot reset device" message that I posted at the top of this comment. In the VM window I can login and run Win10 applications, but there's no sound. The speaker icon on the right side of the bottom bar has a red X and clicking it pops a window with a loading bar and the messages "Detecting problems" and "Checking audio device driver". After a few seconds the loading bar is replaced by the message "Troubleshooting couldn't identify the problem".
I searched the "Cannot reset device" error and I found a forum post [3] where someone said
"You will find that Intel sound is usually grouped with several other devices that you don't want to passthough... I have heard of some people able to get it to work"
I'm stuck.
[1] Full configure line. This is from the Arch User Repository qemu-git package's PKGBUILD file, which I modified to prepend --enable-trace-backends=log --target-list=x86_64-softmmu before running makepkg.
configure \
--enable-trace-backends=log \
--target-list=x86_64-softmmu \
--prefix=/usr \
--sysconfdir=/etc \
--localstatedir=/var \
--libexecdir=/usr/lib/qemu \
--extra-ldflags="$LDFLAGS" \
--smbd=/usr/bin/smbd \
--enable-modules \
--enable-sdl \
--disable-werror \
--enable-vhost-user \
--enable-slirp=system \
--enable-xfsctl \
--audio-drv-list="pa alsa sdl"
[2] https://jcs.org/2018/11/12/vfio
[3] https://forums.unraid.net/topic/76890-cannot-reset-device/
I created a thread on the Arch forum to document my attempts to get qemu vfio passthrough of the HDA controller: https://bbs.archlinux.org/viewtopic.php?pid=1906860#p1906860 I made a little progress by showing that I can passthrough the USB controller (and dump the win10 driver communication). The USB controller is resettable whereas the HDA controller is not. I forgot to install the Windows driver! I'm so embarrassed. Can you tell how bad I am at Windows? XD Samsung distributes drivers through an application called SamsungUpdate. I downloaded SamsungUpdate from the Windows Store, but it crashes when I use it. Specifically, it runs for ~20 seconds then I see a popup that says An additional service package must be installed for Samsung Update to work properly. Do you want to download the installation file now? I click OK and it crashes, ie the SamsungUpdate window disappears. Occasionally the Terms of Use will appear before the popup, but it is always followed by the popup, which is always followed by a crash. :( I have 930SBE and facing the same issue. I willing to help if you need some info or testing to be done. (In reply to Mike Pozulp from comment #17) > I click OK and it crashes, ie the SamsungUpdate window disappears. > Occasionally the Terms of Use will appear before the popup, but it is always > followed by the popup, which is always followed by a crash. :( SamsungUpdate app from store is only front-end, it needs to install win32 module to work correctly. Are you trying to install it inside qemu? I wouldn't bother if there are problems. You can download package with driver (in host Windows) and install it standalone without SamsungUpdate, it will be saved in Downloads/SamsungUpdate folder. Here is the latest package for my machine, it is likely the same for yours. https://www.mediafire.com/file/qj4c9pv0lcz4l92/6.0.8716.1_64.zip/file (let me know if you have trouble downloading, I can upload it elsewhere) (In reply to Takashi Iwai from comment #12) > Maybe yours have no DMIC, hence it binds with the legacy driver. > > Just to be sure, you can try to load with snd_intel_dspcfg.dsp_driver=3 boot > option. Then it will forcibly load with SOF. It might be irrelevant with > the original problem, but still it's worth to try. (In reply to Mike Pozulp from comment #13) > No luck. I rebooted with > > /etc/modprobe.d/dspdriver.conf > options snd_intel_dspcfg dsp_driver=3 > > and still no speaker sound. After booting I tried running alsa_info.sh and > it failed with the message > > alsactl: save_state:1595: No soundcards found... Yes, about the SOF driver. Indeed it doesn't load on 5.6/5.7 kernel for my laptop. But I tested the 5.4.43 kernel and it loads fine there, detect hardware correctly and even loads DSP firmware without errors (well except ABI warning, because I had newer FW binaries). There is still no sound over speakers, but well I haven't debug it much, because there is no point on old kernel. I have reported issue here https://github.com/thesofproject/linux/issues/2151 before I found this bug report. I'm not familiar with sound subsystem, hence I'm counting for some pointer where to look at, because figuring everything out by myself would take probably more time ;) RoninCoder, Jaroslav, and Kacper, I have great news: I see traces! At almost the exact same time that Kacper posted comment 18, I was in #archlinux chatting with an arch user named attackzero who discovered that SamsungUpdate writes an xml log containing download links when it updates drivers. User attackzero ran SU, asked for the audio driver for np930mbe, and gave me the download link: orcaservice.samsungmobile.com/FileDownloader.aspx?FILENAME=BASW-A1542A6N.ZIP All I had to do was boot windows in qemu, download the file, then unzip and double click setup to run the installer, and suddenly I saw the traces. Additionally, the speakers work when I play yt videos in the vm! So the solution was exactly as Kacper describes: forget about SU and simply download the driver then click to install it directly. :) Now begins the long journey to see if we can extract the right information to add Linux support. I'll attach the vfio trace from qemu, the beginning of which looks like this QEMU 5.0.50 monitor - type 'help' for more information (qemu) qemu-system-x86_64: vfio: Cannot reset device 0000:00:1f.3, no available reset mechanism. qemu-system-x86_64: vfio: Cannot reset device 0000:00:1f.3, no available reset mechanism. 3064@1591386653.159507:vfio_region_write (0000:00:1f.3:region0+0xe, 0x7fff, 2) 3064@1591386653.159981:vfio_region_write (0000:00:1f.3:region0+0x8, 0x0, 4) 3064@1591386653.160241:vfio_region_write (0000:00:1f.3:region0+0x8, 0x1, 4) 3064@1591386653.160524:vfio_region_write (0000:00:1f.3:region0+0xc, 0x0, 2) 3064@1591386653.160548:vfio_region_write (0000:00:1f.3:region0+0xe, 0x1, 2) Now we can run QemuHDADump [1]. QHDAD, recommended by Jaroslav in comment 14, dumps the CORB and RIRB buffers of the VM. Building and running with QHDAD results in output which looks like this CORB buffer Address: 0x36e4000 0x0004 Current verb 0x0004 Region0+0x804, 0xc0000000, 4 Current verb 0x0004 Region0+0x804, 0xc0000000, 4 Current verb 0x0004 Region0+0x804, 0xc0000000, 4 Current verb 0x0004 Region4+0x4, 0xf0f0f, 4 Current verb 0x0004 Region4+0x4, 0xf000f0f, 4 (These messages come from print statements in QemuHDADump.c). QHDAD also outputs files containing dumps of the CORB and RIRB buffers. I ran the utilities (included in the QHDAD repo) called ExtractHDADump and frameDumpFormatted and I see 2 files, corb.dump and rirb.dump which look like this 0x00000000: 0xc085ffff 0x01bf5775 0xeb000000 0x1842f650 0x00000010: 0xc74a7402 0x00014841 0x8b480000 0x15ff5049 0x00000020: 0x000079e4 0x58468948 0x48ce8b48 0xe860538b 0x00000030: 0xfffff5c4 0x584e8b48 0xff487e89 0x0079c715 I don't understand this data. Fortunately, we have the HDA spec [2] and we have the ALC269 datasheet [3]. I'm also working my way through this blog post from 2018 [4] which describes how the vfio trace technique was used to develop a quirk to fix the speakers in the Huawei Matebook X. Tomas Espleta contributed the quirk [5]. [1] https://github.com/Conmanx360/QemuHDADump [2] https://www.intel.com/content/dam/www/public/us/en/documents/product-specifications/high-definition-audio-specification.pdf [3] https://www.hardwaresecrets.com/datasheets/alc269.pdf [4] https://jcs.org/2018/11/12/vfio [5] https://patchwork.kernel.org/patch/10764291/ Created attachment 289525 [details]
vfio traces np930mbe
Created attachment 289527 [details]
QemuHDADump terminal output
Created attachment 289529 [details]
QHDAD CORB buffer dump
Created attachment 289531 [details]
QHDAD RIRB buffer dump
I want to share that our patch is in the 5.7 kernel release, and that I'm exploring two ways to dump the CORB because the dump that I posted on 2020-06-05 is no good. It has less than 1000 commands and many are not valid command encodings. Our patch is in the 5.7 kernel release -------------------------------------- Our patch is in the kernel! A very smart Arch user by the name of ronincoder (who co-authored this bug report) discovered that changing the VREF value on NID 0x1a from the default HIZ fixes the headphone jack. I worked with ronincoder to make a kernel patch [1] and Takashi Iwai got it into the 5.7 kernel release! It was also applied to the 5.4 LTS kernel. I booted both 5.7.2 and 5.4.46 and the headphone jack audio is loud and clear. :) Does it work for you? It should if you have a Samsung Notebook 9 Pro NP930SBE-K01US or NP930MBE-K04US (ronincoder's is the former, mine is the latter). You can check your laptop model by running alsa_info.sh and looking at "Board Name". The Realtek ALC298 codec in the NP930SBE-K01US and NP930MBE-K04US identifies itself with "Subsystem Id" 0x144dc169 and 0x144dc176, respectively. If snd_hda_intel sees either of these ids it implements the fix. I'm exploring two ways to dump the CORB --------------------------------------- In comment 14, Jaroslav Kysela suggested dumping the codec communication for the Windows driver using QEMU. We could then parse the dump and replay the communication in Linux using Early Patching or writing another kernel patch. QEMU tells us when the Windows driver writes to the Command Output Ring Buffer (CORB) but not what was written. The CORB is a fixed-length [2] buffer in RAM that wraps around when it fills up (thus "ring buffer"). The Windows driver writes commands to the CORB and the HDA controller reads them. A full description of CORB semantics can be found in the HDA spec. 1) QemuHDADump -------------- QemuHDADump [3] is a C program. It requires building and running QEMU with tracing enabled. The code parses vfio_region_write event traces to identify CORB writes and uses QEMU's pmemsave to save the CORB to a file before the write pointer wraps around from 255 to 0 (and thus begins overwriting commands). I spent some time reading the QemuHDADump code because my dump has less than 1000 commands and many are not valid command encodings. The QemuHDADump author wrote some really nice documentation in which the author said it worked for a few different soundcards, so perhaps I only need to make a small modification to get a good dump on my hardware. I also tried running a fork of QemuHDADump [4]. The original and the fork differ slightly. For example, instead of waiting until the CORB fills before dumping it to a file, the fork writes one command at a time to a FIFO. I'm trying to figure out why reading the FIFO hangs. I noticed that the fork parses writes to the CORBSIZE register 0x4e, which the fork uses to set a struct member named corbsize. My HDA controller never writes the CORBSIZE register. I hardcoded corbsize to 256 but it didn't fix the hang. 2) Tom Briden's method ---------------------- Tom Briden's method [5] uses GDB to determine when to read the CORB and dd to save it to a file. It requires building QEMU with debug symbols. Briden uses GDB to connect to the running QEMU process. Briden sets a conditional breakpoint at the vfio_region_write function in the QEMU source code. GDB breaks when the Windows driver writes to the CORBWP register 0x48 to advance the CORB write pointer. Briden's breakpoint runs dd to dump the CORB to a file. I'm doing something wrong because I see "permission denied" when I run his dd command, even though I'm using sudo dd. My guess is that I'm trying to read a bad section of physical memory. I can thank Briden's method for introducing me to MMIO, which is a way for the CPU to communicate with devices, and a totally new concept to me (I knew nothing about device drivers before I got this laptop lol). Both 1) and 2) seem promising. I will continue to explore them. [1] For reference, our patch made it into Linus' tree as commit 14425f1f521f (ALSA: hda/realtek: Add quirk for Samsung Notebook). [2] I think the CORB in our HDA controller has space for 256 commands, which is the maximum length that the HDA spec allows. Each command is 4 bytes, thus the CORB size is 4x256=1024 bytes. [3] https://github.com/Conmanx360/QemuHDADump [4] https://github.com/abridgewater/QemuHDADump [5] https://bugzilla.kernel.org/show_bug.cgi?id=189331#c229 I'm running a slightly different Samsung book (Samsung Galaxy Flex Book 2020), with, what appears the same hardware, though my subsystem is listed slightly differently. alsa-info : http://alsa-project.org/db/?f=c71e7b5f2abd93ea9f0d5a0dc132f517e582885c In the above alsa-info, i'm not using the correct kernel, though I have tried it, and since my subsystem is : 0x144dc189 I cannot hear the fix from the above patched kernels. Is there any way for me to have the above fix applied on my system to see if it resolves my no internal speaker / no headphone issues? I applied the fix with the above early patching method and it does indeed work for my hardware Subsystem Id: 0x144dc189 So, I now have headphone audio. Is there anything I can provide to help with the internal speaker issue? Created attachment 290897 [details]
Patch to add quirk for Samsung Galaxy Flex Book
> I applied the fix with the above early patching method and it does indeed > work for my hardware Subsystem Id: 0x144dc189 > So, I now have headphone audio. Wonderful! I submitted a patch to lkml (see attached). Thanks to you, other Flex Book owners will get headphone audio now too. Nice job! =) > Is there anything I can provide to help with the internal speaker issue? Yes. Step 1 get a good trace Step 2 minimize the verbs I outlined two strategies for Step 1 in Comment 24, but I haven't made any progress since I wrote the comment. Step 2 is best described by this excerpt from https://jcs.org/2018/11/12/vfio. The author was running BSD instead of Linux, but the process will be almost identical: > The full log of VFIO PCI activity from the Windows driver was over 65,000 > lines and contained 3,150 CORB commands, which is a lot to sort through. It > took me a couple more days to reduce that down to a small subset that was > actually required to activate the second speaker, and that could only be done > through trial and error: > Boot OpenBSD with the full list of CORB commands in the azalia driver > Comment out a group of them > Compile kernel and install it, halt the QEMU guest > Suspend and wake the laptop, resetting PCI power to the audio device to reset > the speaker/Dolby initialization and ensure the previous run isn’t > influencing the current test (I’m guessing there is an easier to way to reset > PCI power than suspending the laptop, but oh well) > Start QEMU, boot OpenBSD with the new kernel > Play an MP3 with mpg123 which has alternating left- and right-channel audio > and listen for both channels to play > This required a dozen or so iterations because sometimes I’d comment out too > many commands and the right speaker would stop working. Other times the > combination of commands would hang the controller and it wouldn’t process any > further commands. At one point the combination of commands actually flipped > the channels around so the right channel audio was playing through the left > speaker. Created attachment 290947 [details] Patch to add model alc298-samsung-headphone A couple users who own Samsung Galaxy Book Ion NT950XCJ-X716A laptops are struggling with the very quiet and distorted headphone output bug [1]. Expose the quirk which fixed the bug as a model so they can try the quirk more easily than editing and recompiling with their subsystem id. [1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1851518 Created attachment 292009 [details] Patch to add quirk for Samsung Galaxy Book Ion The Galaxy Book Ion uses the same ALC298 codec as other Samsung laptops which have the no headphone sound bug, like my Samsung Notebook. The Galaxy Book owner confirmed that this patch fixes the bug [1]. [1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1851518
Hi Jaroslav,
I have been working with Mike on completing steps 1 and 2 above on my Galaxy Book Ion. I have made some progress, but still no sound from the speakers. Mike suggested posting the progress here to see if you had any ideas on thoughts on what we might be missing.
A brief summary (certainly more detail available as desired...)
I confirmed that I have a laptop with the alc298 realtek audio device, and have installed (successfully) the headphone patch from Mike.
From lspci -nn
00:1f.0 ISA bridge [0601]: Intel Corporation Device [8086:0284]
00:1f.3 Multimedia audio controller [0401]: Intel Corporation Device [8086:02c8]
00:1f.4 SMBus [0c05]: Intel Corporation Device [8086:02a3]
00:1f.5 Serial bus controller [0c80]: Intel Corporation Comet Lake SPI (flash) Controller [8086:02a4]
I downloaded the source code for qemu-5.1.0, modified it for better tracing, and installed it locally.
I created a new bare bones windows VM and have completed all the steps for vfio pass through of the audio iommu group (my machine has 4 device in the iommu group 9, and I have to pass through the full group to successfully run the VM):
From find /sys/kernel/iommu_groups/ -type l
/sys/kernel/iommu_groups/9/devices/0000:00:1f.0
/sys/kernel/iommu_groups/9/devices/0000:00:1f.5
/sys/kernel/iommu_groups/9/devices/0000:00:1f.3
/sys/kernel/iommu_groups/9/devices/0000:00:1f.4
I am fairly confident this is all working as expected. I do not receive any errors starting the VM and windows recognizes the realtek audio device. Most importantly, the speakers work perfectly inside the windows VM.
With the enhanced logging I am able to get CORB values in two different manners. I am able to use the QemuHDADump program as suggested by Mike and I am able to get nicely formatted CORB values... looks something like this :
0x000019c0: 0x012b0000 0x013f000c 0x013f000d 0x013f000f
0x000019d0: 0x013f000e 0x013f0500 0x013f0700 0x013f1c00
0x000019e0: 0x013b2000 0x013b0000 0x014f000c 0x014f000e
0x000019f0: 0x014f000f 0x014f0012 0x014f000e 0x014f0100
0x00001a00: 0x014f0500 0x014f0700 0x014f1c00 0x014f0200
0x00001a10: 0x014ba000 0x014b8000 0x017f000c 0x017f000e
0x00001a20: 0x017f000f 0x017f0012 0x017f000e 0x017f0100
0x00001a30: 0x017f0500 0x017f0700 0x017f0800 0x017f0c00
0x00001a40: 0x017f1c00 0x017f0200 0x017ba000 0x017b8000
0x00001a50: 0x018f000c 0x018f000d 0x018f000f 0x018f000e
.....
I also modified the qemu tracing as suggested in the BSD article and I am able to get CORB values directly from stdout... they look something like :
CORB[195] = 0x517ff00 (caddr:0x0 nid:0x51 control:0x7ff param:0x0)
CORB[196] = 0xf0000 (caddr:0x0 nid:0x0 control:0xf00 param:0x0)
CORB[197] = 0xf0002 (caddr:0x0 nid:0x0 control:0xf00 param:0x2)
CORB[198] = 0x1f2000 (caddr:0x0 nid:0x1 control:0xf20 param:0x0)
CORB[199] = 0x2050000 (caddr:0x0 nid:0x20 control:0x500 param:0x0)
CORB[200] = 0x20c0000 (caddr:0x0 nid:0x20 control:0xc00 param:0x0)
CORB[201] = 0x1ff1c00 (caddr:0x0 nid:0x1f control:0xf1c param:0x0)
CORB[202] = 0x2050099 (caddr:0x0 nid:0x20 control:0x500 param:0x99)
.....
I have refined my setup and get pretty consistent values now, and generally speaking, the output from both techniques is similar.
To 'replay' the values I have tried directly converting these values to HDA verbs, I have tried early patching, and I have tried using a modified form of the kernel patch Mike provided to create new custom kernels. Again, so far I have had no luck in getting sound to play in linux through the speakers. I have tried using the tracing to mimic the VM boot process, playing sound on the VM, and going into device manager and disabling and re-enabling the realtek audio device. I have separately captured recordings of each of these events and tried all 3 methods to play them back.
Its very possible I am not translating the CORB values to usable data properly. I am not sure if anyone has guidance on how to do that...
For the QemuHDADump data I converted the hex 8 values to 32 bit integeres and then converted them back using the HDA spec...
HDA Spec CORB 32 bit format
The controller generated (outbound) Verb format
31:28 Codec Address
27:20 Node ID
19:0 Verb Payload
So as an example :
0xca8e6ab8
Becomes (I guessed at how to split the "verb payload"):
1100 0xc
10101000 0xa8
11100110101010111000 0xe6a 0xb8
Which becomes (if using HDA verbs) :
sudo hda-verb /dev/snd/hwC0D0 0xa8 0xe6a 0xb8
Or this (if using kernel patch ) :
{ 0xa8, 0xe6a, 0xb8 },
For the BSD style logging its a shorter translation...
So as an example, this :
CORB[204] = 0x2050099 (caddr:0x0 nid:0x20 control:0x500 param:0x99)
Would become either :
sudo hda-verb /dev/snd/hwC0D0 0x20 0x500 0x99
OR
{ 0x20, 0x500, 0x99 },
At this point I consistently see the same set of nids in the output, which feels like what I would expect. My concerns are that I might not be translating the CORB values correctly, or we perhaps need the trace for the AKG smart amp which is not directly traced in this immou group. I don't see anything in lspci that jumps out at me as the amp being separate hardware.
Nevermind, Jaroslav. We worked through it on the other thread. (In reply to John Hoff from comment #32) > Nevermind, Jaroslav. We worked through it on the other thread. Which other thread? (In reply to MikeYo from comment #33) > (In reply to John Hoff from comment #32) > > Nevermind, Jaroslav. We worked through it on the other thread. > > Which other thread? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1851518 The script with the 358 verbs required for sound (at least on the samsung galaxy book ion) is attached in that thread. It was created using the technique suggested by Mike Pozulp here. (In reply to terrydrever from comment #26) > I applied the fix with the above early patching method and it does indeed > work for my hardware Subsystem Id: 0x144dc189 > > So, I now have headphone audio. > > Is there anything I can provide to help with the internal speaker issue? I have the same exact laptop as yours and still stuck with no speakers audio. Were you able to figure this out or do what Mike Pozulp suggested in his reply to you? (I would have done it myself, but still a linux n00b, no idea how to get this done myself) By the way, the wonderful MrEen was trying to assist me with this Galaxy Book Flex 2020 (Subsystem Id: 0x144dc189) in June, but unfortunately to no avail: https://forums.linuxmint.com/viewtopic.php?f=90&t=321359&start=40 Samsung NP930SBE - the headphones have sound, the speakers do not. (In reply to indewer from comment #37) > Samsung NP930SBE - the headphones have sound, the speakers do not. uname -r 5.8.0.44-generic (In reply to indewer from comment #37) > Samsung NP930SBE - the headphones have sound, the speakers do not. uname -r 5.8.0.44-generic Created attachment 296845 [details]
Patch for speaker amp
Please review this patch, I finally put it together. I'm open for suggestions, I tried to do as little code duplication as possible and it turned out not that big after all.
Thanks,
Kacper
The plain snd_hda_codec_write() calls should be rather replaced with alc_write_coef_idx(), e.g. snd_hda_codec_write(codec, 0x20, 0, AC_VERB_SET_COEF_INDEX, idx); snd_hda_codec_write(codec, 0x20, 0, AC_VERB_SET_PROC_COEF, val); can be replaced a single call of alc_write_coef_idx(codec, idx, val); The succeeding call of AC_VERB_SET_PROC_COEF means to set a value in the next index. That is, snd_hda_codec_write(codec, 0x20, 0, AC_VERB_SET_COEF_INDEX, idx); snd_hda_codec_write(codec, 0x20, 0, AC_VERB_SET_PROC_COEF, val1); snd_hda_codec_write(codec, 0x20, 0, AC_VERB_SET_PROC_COEF, val2); is equivalent with alc_write_coef_idx(codec, idx, val1); alc_write_coef_idx(codec, idx+1, val2); And the COEF value can be 16bit, and the high byte can be put in the register argument, i.e. the call snd_hda_codec_write(codec, 0x20, 0, 0x4b0, 0x11); is equivalent with snd_hda_codec_write(codec, 0x20, 0, AC_VERB_SET_PROC_COEF, 0xb011); So, it looks like that all calls there are about setting up COEF 0x23 to 0x26 multiple times. And, unless you're 100% sure, better to keep the old quirk code for the entries you didn't actually test. Created attachment 297789 [details] Patch for speaker amp v2 > The plain snd_hda_codec_write() calls should be rather replaced with > alc_write_coef_idx() Thanks, for explaining this, it makes more sense now why order was so important. I changed it, although using alc_write_coef_idx makes more writes as it updates index always :) Also changed array to ushort, there is only one value that needs that, but I would trade those few bytes instead duplicating last set in code. > And, unless you're 100% sure, better to keep the old quirk code for the > entries you didn't actually test. I'm actually 99% sure it is the same platform, just with different branding and form factor. Bump. Could we move forward with this? I'm open for suggestions what to do to make it upstreamed. It's is only kernel patch that forces me to manually compile it for my laptop. Please prepare the patch in a proper format and submit it to the upstream alsa-devel ML. Put me to Cc. You can find the addresses in MAINTAINERS file. Before the submission, check the patch with scripts/checkpatch.pl. This will catch most of coding style issues. Some formalities about the patch submission is found in Documentation/process/submitting-patches.rst. Especially don't forget to give your Signed-off-by line. Bump. I'm a total noob, and I use Pop!_OS as my daily driver and have no idea how to fix this issue. If anyone can help me I would really appreciate it! This issue is still present in my Razer 14 (2023) Same issue here with a Razer Blade 18 - 2023 Bump. I have the same issue with my Razer Blade 14 (2023) Same issue with my new Razer Blade 14 (2023) Created attachment 305667 [details]
Razer Blade 14 2023 Realtek HD dump and linux codec dump
Comment on attachment 305667 [details]
Razer Blade 14 2023 Realtek HD dump and linux codec dump
Attached Realtek HD audio dump data and linux codec dump for Razer Blade 14 2023.
(In reply to jamir from comment #53) > Comment on attachment 305667 [details] > Razer Blade 14 2023 Realtek HD dump and linux codec dump > > Attached Realtek HD audio dump data and linux codec dump for Razer Blade 14 > 2023. Looks like this dump can be applied somehow with hda-verb. Have you tried it? Any success? (In reply to dkeysil from comment #54) > (In reply to jamir from comment #53) > > Comment on attachment 305667 [details] > > Razer Blade 14 2023 Realtek HD dump and linux codec dump > > > > Attached Realtek HD audio dump data and linux codec dump for Razer Blade 14 > > 2023. > > Looks like this dump can be applied somehow with hda-verb. Have you tried > it? Any success? I did try running the necessary verb file for galaxy book without success (no audio from internal speakers). I am not sure how to create the verb file out of a windows dump file. Is there some instruction I can follow? This my stab at creating the commands to run against the razer blade 14 (2023). https://gist.github.com/AdrielVelazquez/d50d4019d519fb856db6bce3da4f099f I've also added it as attachments. Feel free to sanity check me if it's done correctly. Card two according to the aplay output ``` ➜ ALC298 aplay --list-devices **** List of PLAYBACK Hardware Devices **** card 0: NVidia [HDA NVidia], device 3: HDMI 0 [HDMI 0] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: NVidia [HDA NVidia], device 7: HDMI 1 [HDMI 1] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: NVidia [HDA NVidia], device 8: HDMI 2 [HDMI 2] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: NVidia [HDA NVidia], device 9: HDMI 3 [HDMI 3] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: Generic [HD-Audio Generic], device 3: HDMI 0 [HDMI 0] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: Generic [HD-Audio Generic], device 7: HDMI 1 [HDMI 1] Subdevices: 1/1 Subdevice #0: subdevice #0 card 2: Generic_1 [HD-Audio Generic], device 0: ALC298 Analog [ALC298 Analog] Subdevices: 0/1 Subdevice #0: subdevice #0 ``` Created attachment 305685 [details]
Python file to get verbs + index command
Created attachment 305686 [details]
Attempt at the razer path with all the values
How did you get an output like that. My card I don't think is recognized like yours. Here is the output of my aplay aplay --list-devices ✔ **** List of PLAYBACK Hardware Devices **** card 0: NVidia [HDA NVidia], device 3: HDMI 0 [HDMI 0] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: NVidia [HDA NVidia], device 7: HDMI 1 [HDMI 1] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: NVidia [HDA NVidia], device 8: HDMI 2 [HDMI 2] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: NVidia [HDA NVidia], device 9: HDMI 3 [HDMI 3] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: sofhdadsp [sof-hda-dsp], device 0: HDA Analog (*) [] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: sofhdadsp [sof-hda-dsp], device 3: HDMI1 (*) [] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: sofhdadsp [sof-hda-dsp], device 4: HDMI2 (*) [] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: sofhdadsp [sof-hda-dsp], device 5: HDMI3 (*) [] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: sofhdadsp [sof-hda-dsp], device 31: HDA Analog Deep Buffer (*) [] Subdevices: 1/1 Subdevice #0: subdevice #0 (In reply to Adriel V from comment #58) > Created attachment 305686 [details] > Attempt at the razer path with all the values I ran the script after replacing hwC0D0 with hwC2D0. It took a while to execute but unfortunately I still don't get any sound during, after the execution of the script. The card for me is also listed as Card 2. card 2: Generic_1 [HD-Audio Generic], device 0: ALC298 Analog [ALC298 Analog] Subdevices: 0/1 Subdevice #0: subdevice #0 +, tried to run this hda-verb script with my razer blade 16 (replace hwC0D0 with hwC1D2) and no success. There is no card 2 in aplay --list-devices ls /dev/snd by-path hwC0D0 pcmC0D3p pcmC0D9p pcmC1D31p pcmC1D5p seq controlC0 hwC1D0 pcmC0D7p pcmC1D0c pcmC1D3p pcmC1D6c timer controlC1 hwC1D2 pcmC0D8p pcmC1D0p pcmC1D4p pcmC1D7c The script I provided was ALL the hda-verbs that @jamir provided. I still need to slowly go through the sequence of commands to see which one actually sets the volume. Unfortunately a manual process. Similar to this process here. https://github.com/thesofproject/linux/issues/4055#issuecomment-1332331409 I've assigned a 5 second sleep after each command, and wait to hear a sound (if any) (In reply to Adriel V from comment #62) > The script I provided was ALL the hda-verbs that @jamir provided. > > I still need to slowly go through the sequence of commands to see which one > actually sets the volume. Unfortunately a manual process. Similar to this > process here. > > https://github.com/thesofproject/linux/issues/4055#issuecomment-1332331409 > > I've assigned a 5 second sleep after each command, and wait to hear a sound > (if any) In the script I noticed a zero after the device is that expected ? I thought the nid = 0x20, verb = 0x500, and param = 0x00 example : sudo hda-verb /dev/snd/hwC2D0 0 0x20 0x500 0x00 And also there are only 2 types of verbs we have 0x500 (AC_VERB_SET_COEF_INDEX) and 0x400 (AC_VERB_SET_PROC_COEF) whereas Samsung Galaxy Book had others (0x423, 0x4b0). Script is not correct 0 after hardware is not correct (according to my understanding), also script will set gain table nothing more. This will not enable amplifier from my understanding. Looking at other scripts they are way more complicated and with many more verbs inside. Tested on my Razer Blade 14, nothing change - headphones are working, speakers don't Any progress here regarding the Razer Blade 14 2023? Created attachment 305783 [details]
Razer Blade 14 2023 - ALC298 - HDAAnalyzer screenshots
I captured some screenshots from running of HDAAnalyzer on the laptop. I do see nodes 0x03, 0x0d, and 0x17 are related and I wasn't able to make Audio output (0x03) Active in Node(0x0d). I am not sure if this is the cause why we don't hear sound from the internal speaker or its something else. Need some experts to look into this.
Sadly proposed version of Qemu in earlier posts are too old to build, I have to find a way to patch more recent version. If someone already had done it please point repo for it. OK I managed it to work and I passed sound card to virtual machine. But there is no sound out of the speakers again only from headphone jack. I can not install anything from AMD because installer do not pass checks. So corbs I have are useless. Maybe check with Windows 11 ? Same with windows 11 only headphone jack is working. Did you try the drivers posted on razer's website ? https://mysupport.razer.com/app/answers/detail/a_id/13030/~/razer-blade-14-%282023%29-%7C-rz09-0482x-support-%26-faqs Not sure if it makes a difference (AMD APU Driver). They are same as the one I downloaded from AMD. Tomorrow will try to install them again with cpu=host Well no go. I even installed drivers from Razer and nothing changed. I think we need sound driver from Realtek but I don't know how to install it. Interesting part is that my old Razer Blade 2020 is with same ALC298 but speakers are working under Linux. Even tried hdajackretask to connect pins to speakers but nothing changed. Having you tried passing more than just 1022:15e3 and see the installation goes through? Like passing device at Group 18, 22 etc. IOMMU Group 17 65:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Phoenix1 [1002:15bf] (rev c1) IOMMU Group 18 65:00.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] Rembrandt Radeon High Definition Audio Controller [1002:1640] IOMMU Group 19 65:00.2 Encryption controller [1080]: Advanced Micro Devices, Inc. [AMD] Family 19h (Model 74h) CCP/PSP 3.0 Device [1022:15c7] IOMMU Group 1 00:01.1 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Device [1022:14ed] IOMMU Group 20 65:00.3 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] Device [1022:15b9] IOMMU Group 21 65:00.4 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] Device [1022:15ba] IOMMU Group 22 65:00.5 Multimedia controller [0480]: Advanced Micro Devices, Inc. [AMD] ACP/ACP3X/ACP6x Audio Coprocessor [1022:15e2] (rev 63) IOMMU Group 23 65:00.6 Audio device [0403]: Advanced Micro Devices, Inc. [AMD] Family 17h/19h HD Audio Controller [1022:15e3] Have you tried passing more than just 1022:15e3 and see the installation goes through? Like passing device at Group 18, 22 etc. IOMMU Group 17 65:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Phoenix1 [1002:15bf] (rev c1) IOMMU Group 18 65:00.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] Rembrandt Radeon High Definition Audio Controller [1002:1640] IOMMU Group 19 65:00.2 Encryption controller [1080]: Advanced Micro Devices, Inc. [AMD] Family 19h (Model 74h) CCP/PSP 3.0 Device [1022:15c7] IOMMU Group 1 00:01.1 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Device [1022:14ed] IOMMU Group 20 65:00.3 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] Device [1022:15b9] IOMMU Group 21 65:00.4 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] Device [1022:15ba] IOMMU Group 22 65:00.5 Multimedia controller [0480]: Advanced Micro Devices, Inc. [AMD] ACP/ACP3X/ACP6x Audio Coprocessor [1022:15e2] (rev 63) IOMMU Group 23 65:00.6 Audio device [0403]: Advanced Micro Devices, Inc. [AMD] Family 17h/19h HD Audio Controller [1022:15e3] I have passed device from group 22 and there is a driver for it but it is with yellow exclamation mark because windows can not reset it, also sound device is with generic drive, and not realtek one A have tried hda analizer but it is not working at all on my kernel. Says incompatible format I am on 6.7.2 kernel. I have the hda-analyzer working if you want me to try something. I tried changing volume sliders, unmuted things. Nothing helped. I had attached a document with some screenshots. By the way the sound device with the Realtek codec is Group 23 (1022:15e3), isn't it? Yes device is in group 23, but I think we need driver for it which I can not find on the Razer Support. It is preinstalled on windows image of the laptop. Created attachment 305825 [details]
All corb frames from Razer Blade 14 with sound in VM
I have successfully played sound trough speakers inside Qemu VM. I am attaching corb dump that I had. But under linux there is no sound still.
Also there is bug in microphone, Linux set in group 3 it is in group 5 Well I can not make Linux to play sound trough speakers. Qemu VM is working. I suspect that there is something that is not inited correctly in BIOS and driver in windows just fix it, but I can not find what it is it. Tried other guides and even played whole file with CORBS but no sound. Windows driver have some kind of debug log that is written in registry this is what I found: _HardWareInit,CaplessHookDACNumber=03 _HardWareInit,HeadSetUnPlugDisableHeadSetMics=0 _AzPinComplex::DeviceTypeToCurrentCfg,DevType=22 What is Capless Hook DAC ? This DAC is for the speakers, 0x02 is for headphones. So some kind of init is missing? As I know Razer Blade 2020 is using exactly same ALC298 and speakers are working. Maybe ACPI dump from it will help to see if there is extra init. Same issue with the new Razer Blade 16 2024 on Ubuntu 22.04 with a new audio card (ALC1220): aplay --list-devices **** List of PLAYBACK Hardware Devices **** card 0: NVidia [HDA NVidia], device 3: HDMI 0 [HDMI 0] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: NVidia [HDA NVidia], device 7: HDMI 1 [HDMI 1] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: NVidia [HDA NVidia], device 8: HDMI 2 [HDMI 2] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: NVidia [HDA NVidia], device 9: HDMI 3 [HDMI 3] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: J380 [Jabra Link 380], device 0: USB Audio [USB Audio] Subdevices: 0/1 Subdevice #0: subdevice #0 card 2: Generic [HD-Audio Generic], device 0: ALC1220 Analog [ALC1220 Analog] Subdevices: 1/1 Subdevice #0: subdevice #0 card 2: Generic [HD-Audio Generic], device 1: ALC1220 Digital [ALC1220 Digital] Subdevices: 1/1 Subdevice #0: subdevice #0 (In reply to Rares from comment #84) > Same issue with the new Razer Blade 16 2024 on Ubuntu 22.04 with a new audio > card (ALC1220): > > > aplay --list-devices > **** List of PLAYBACK Hardware Devices **** > card 0: NVidia [HDA NVidia], device 3: HDMI 0 [HDMI 0] > Subdevices: 1/1 > Subdevice #0: subdevice #0 > card 0: NVidia [HDA NVidia], device 7: HDMI 1 [HDMI 1] > Subdevices: 1/1 > Subdevice #0: subdevice #0 > card 0: NVidia [HDA NVidia], device 8: HDMI 2 [HDMI 2] > Subdevices: 1/1 > Subdevice #0: subdevice #0 > card 0: NVidia [HDA NVidia], device 9: HDMI 3 [HDMI 3] > Subdevices: 1/1 > Subdevice #0: subdevice #0 > card 1: J380 [Jabra Link 380], device 0: USB Audio [USB Audio] > Subdevices: 0/1 > Subdevice #0: subdevice #0 > card 2: Generic [HD-Audio Generic], device 0: ALC1220 Analog [ALC1220 Analog] > Subdevices: 1/1 > Subdevice #0: subdevice #0 > card 2: Generic [HD-Audio Generic], device 1: ALC1220 Digital [ALC1220 > Digital] > Subdevices: 1/1 > Subdevice #0: subdevice #0 My mistake the sound card is the same on new Razer Blade 16 2024 ALC298 I have to report my progress. I tried to made new dump this time with https://github.com/abridgewater/QemuHDADump with proposed changes of QEMU. Dump is somewhat different as it is made when command is submitted to codec and not dumped from memory buffer. What I found is allot of consequent writes in node 0x20 with index 0x23 where first write looks like address that is incremented. Example: index 26 - read 0x02050026 0x020c0000 index 89 - write 0x02050089 0x02040000 index 23 - write 0x02050023 0x0204c203 0x02040000 0x02040084 0x0204b031 index 26 - read 0x02050026 0x020c0000 index 89 - write 0x02050089 0x02040000 index 23 - write 0x02050023 0x0204c206 0x02040000 0x02040078 0x0204b031 etc. Here first write in index 23 is c203, then c206. There is many such address. Also "packet" always stops with b031. And starts by writing in index 89. Also interesting part was that after capture I reboot computer to remove vfio_pci. And just by putting: sudo hda-verb /dev/snd/hwC1D0 0x20 0x500 0x89 sudo hda-verb /dev/snd/hwC1D0 0x20 0x400 0x0000 sudo hda-verb /dev/snd/hwC1D0 0x20 0x500 0x23 sudo hda-verb /dev/snd/hwC1D0 0x20 0x400 0xc121 sudo hda-verb /dev/snd/hwC1D0 0x20 0x400 0x0000 sudo hda-verb /dev/snd/hwC1D0 0x20 0x400 0x000b sudo hda-verb /dev/snd/hwC1D0 0x20 0x400 0xb031 I had sound in Linux too. There is no substantial difference in pins and nodes that I can see. Until complete power off I have sound on speakers in Linux. Now will explore this big sequence that is repeating during VM boot to see if this is some kind of upload to DSP and pin rerouting. Hello, I am not sure if this is the right place but I have been following this report for some time and trying to fix my speakers on a different machine: LG Gram Style 14, which has the same ALC298 but the Samsung verb list does not fix it completely (which is mostly expected) with unbalanced sound. After trying all available methods, I have been able to generate an output by enabling tracing in qemu and also applying a patch to capture 'hidden' CORB writes by Joshua Stein [1]. Now comes the step of extraction of the verbs from the dump (as mentioned in this very useful thread). I tried both forks of QemuHDADump listed here (from Conmanx360 and abridgewater) and both did work sort of after a little modification, which was to set the start offset for each line to be 0 (my dump does not have pid and date annotations). They both fail to generate the said frame files and the stdout output is also off. My next move would have been to write a simple parser of the commands to extract the data from each line and convert it to a verb command ready to be executed in a terminal directly but since the scripts do things unbeknownst to me, it seemed wise to consult the experts on this. All help is immensely welcomed. Please post if you need more info on this. [1] https://jcs.org/2018/11/12/vfio Created attachment 305973 [details]
LG Gram Style 14 (ALC298) CORB Dump
The generated corb dump from the windows VM.
I've been following this thread as well as others to try to get audio to work on a razor 16" 2023 laptop. One definate hurdle I've run into is that using virtualbox the audio for a windows vm still doesn't work. What VM software is everyone using to recreate the audio working in the vm? (In reply to jdkell3 from comment #89) > I've been following this thread as well as others to try to get audio to > work on a razor 16" 2023 laptop. One definate hurdle I've run into is that > using virtualbox the audio for a windows vm still doesn't work. What VM > software is everyone using to recreate the audio working in the vm? you have to use Qemu with PCIE pass trough to pass codec to virtual machine and use windows drivers to init it Gotcha. I assume you need to modify the grub line per the instructions in Qemu/wiki?
> On Apr 15, 2024, at 08:39, bugzilla-daemon@kernel.org wrote:
>
> https://bugzilla.kernel.org/show_bug.cgi?id=207423
>
> --- Comment #90 from Dimitar Atanasov (phusho@yahoo.com) ---
> (In reply to jdkell3 from comment #89)
>> I've been following this thread as well as others to try to get audio to
>> work on a razor 16" 2023 laptop. One definate hurdle I've run into is that
>> using virtualbox the audio for a windows vm still doesn't work. What VM
>> software is everyone using to recreate the audio working in the vm?
>
> you have to use Qemu with PCIE pass trough to pass codec to virtual machine
> and
> use windows drivers to init it
>
> --
> You may reply to this email to add a comment.
>
> You are receiving this mail because:
> You are on the CC list for the bug.
Well I think I got it working, but surely someone has figured out how to make this work without needing to start a VM every time the system starts. Right now my plan of attack is to have a service file that starts up the VM, runs the verbs commands then shuts down, but that seems asinine. Created attachment 306155 [details]
Razer Blade 14 2023 enable internal speakers
I think I got it to work now without the need of a VM. I need someone else to confirm. Please run the hda-verb command and see if the speakers are enabled after that. I will need help cleanup the file as I know of sure not all of it is required to get the speakers working.
Created attachment 306157 [details]
RB14 2023 Enable Internal Speakers - Ver # 2
Cleaned up the file a little and made sure it still works.
Tested on razer 18 2023 and it works. I have sound now. Haven't tested everything, but just needed to change the device to 1D0 instead of 2D0 Is your grub line still modified or do you think that's still necessary? RB 16 2023 - changed 2D0 to 1D0 and just executed the second script and it's finally working Thanks a lot Jamir! (In reply to jdkell3 from comment #96) > Is your grub line still modified or do you think that's still necessary? No need, since we are not passing the device to a VM anymore. Created attachment 306158 [details] attachment-10233-0.html Dude it totally worked! Well done! I’m shipping you your booze of choice. > On Apr 15, 2024, at 13:56, bugzilla-daemon@kernel.org wrote: > > https://bugzilla.kernel.org/show_bug.cgi?id=207423 > > --- Comment #98 from jamir (soundhermit@gmail.com) --- > (In reply to jdkell3 from comment #96) >> Is your grub line still modified or do you think that's still necessary? > > No need, since we are not passing the device to a VM anymore. > > -- > You may reply to this email to add a comment. > > You are receiving this mail because: > You are on the CC list for the bug. (In reply to jdkell3 from comment #99) > Created attachment 306158 [details] > attachment-10233-0.html > > Dude it totally worked! > > Well done! I’m shipping you your booze of choice. > > > On Apr 15, 2024, at 13:56, bugzilla-daemon@kernel.org wrote: > > > > https://bugzilla.kernel.org/show_bug.cgi?id=207423 > > > > --- Comment #98 from jamir (soundhermit@gmail.com) --- > > (In reply to jdkell3 from comment #96) > >> Is your grub line still modified or do you think that's still necessary? > > > > No need, since we are not passing the device to a VM anymore. > > > > -- > > You may reply to this email to add a comment. > > > > You are receiving this mail because: > > You are on the CC list for the bug. Awesome. Thanks, but I am taking a break. (In reply to jamir from comment #94) > Created attachment 306157 [details] > RB14 2023 Enable Internal Speakers - Ver # 2 > > Cleaned up the file a little and made sure it still works. I confirm this is also working on my Razer Blade 16 2024. You rock! I only had to change the card to hwC1D0 in the script. Thanks! After also chaning to hwC1D0 the internal speakers on Razer Blade 15 - RZ09-0485 (2022) are finally working for me. Thank you Jamir! (In reply to jamir from comment #94) > Created attachment 306157 [details] > RB14 2023 Enable Internal Speakers - Ver # 2 > > Cleaned up the file a little and made sure it still works. Works for me too on RB14 2023, thanks Jamir! I will be looking into what worked and next steps. Jamir's script (with the hwC1D0 change) works to get speakers functional on my Razer Blade 16 2023 but I noticed two issues: 1) Audio pops when starting/stopping in KDE using Pipewire 2) Audio is extremely tinny, likely due to the embedded subwoofers not functioning After upgrading to Fedora 40, the V2 script no longer works for the razer blade 14 I've tested in the last three Kernel versions I have on my system, 6.8.8-0 6.8.7-350 6.8.7-250 Also tested all the sounds cards under `/dev/snd` hwC0D0/C1D0/C2D0 I tested on my Razer Blade 16 2024, on a Live USB, in Ubuntu 24.04 (Kerenel 6.8) and I confirm is still working with hwC1D0. Thanks! |