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!