@gannon1 I am tracking what your saying concept wise. Here is a summary of what I did today, in part just to help me clarify my thoughts and in part so you can maybe correct any gaps and save me troubleshooting time :). - I have gone through all the documents in the wiki for QemuHDADump and as far as I can tell it is running as expected on my PC and creating good logs. I am able to see the logging happening in real-time and I get the frame binary files. I am also able to use his extract and format programs to "see" the data as text. As an example, the attached file named CORB has the final formatted output from disabling and re-enabling the realtek device in windows.... - Looking at the HDA spec, this seems to be the only detailed description of the CORB entries : HDA Spec CORB 32 bit format The controller generated (outbound) Verb format Bits 31:28 Codec Address Bits 27:20 Node ID Bits 19:0 Verb Payload It is not currently clear to me how to parse the "verb payload" or how to map these CORB values into anything useful. - Several of the documents you listed and your comments mention playing back or using the values to turn on the sound. I assume (maybe incorrectly), that we are trying to a) produce a list of HDA Verb commands that match each CORB entry to prove the sound turns on and then B) work to whittle down the list to the minimum required ones. Part B will be effort, but I think that will just be applied time once we achieve Part A. For Part A, again my assumption, we are trying to convert CORB values into the HDA Verb format : HDA Verb format The hwdep device name The widget NID The verb The parameter - Since I was stuck on what to do with the output from QemuHDADump, I went back and read the other articles more, specifically the BSD article. That author took a different approach and instead of using the QemuHDADump program, he just altered Qemu to give him more info in the output. His source code was available so I worked with that to try and replicate his results. I couldn't just use his common.c file directly because we are on different version of qemu, but I was able to modify the common.c file on my version of qemu, and then remake qemu successfully. So now, instead of just getting lines like this : 15469@1598294292.270884:vfio_region_write (0000:00:1f.3:region0+0x48, 0xad, 2) 15469@1598294292.270975:vfio_region_write (0000:00:1f.3:region0+0x20, 0x40000000, 4) 15469@1598294292.270983:vfio_region_write (0000:00:1f.3:region0+0x5d, 0x1, 1) I get more information, like this : 15469@1598294292.272359:vfio_region_write (0000:00:1f.3:region0+0x5d, 0x1, 1) RIRBWP advance to 185, last WP 183 CORB caddr:0x9 nid:0x47 control:0x407 param:0x20 response:0x64756c63 (ex 0x6f466465) CORB caddr:0x0 nid:0x0 control:0x1 param:0xe6 response:0x65735572 (ex 0x544e4900) RIRBWP advance to 185, last WP 185 RIRBWP advance to 185, last WP 185 RIRBWP advance to 185, last WP 185 15469@1598294292.272436:vfio_region_write (0000:00:1f.3:region0+0x20, 0xc0000000, 4) CORBWP advance to 187, last WP 185 CORB[186] = 0x0 (caddr:0x0 nid:0x0 control:0x0 param:0x0) CORB[187] = 0x0 (caddr:0x0 nid:0x0 control:0x0 param:0x0) 15469@1598294292.272522:vfio_region_write (0000:00:1f.3:region0+0x48, 0xbb, 2) I think the most useful parts here are the CORB[] lines (for example) : CORB[218] = 0x9cac8480 (caddr:0x9 nid:0x4a control:0xc84 param:0x80) This would at least seem like it could be mapped to an HDA verbs, maybe like so sudo hda-verb /dev/snd/hwC0D0 0x4a 0xc84 0x80 - So with that change, I then recorded all the traffic during a re-enable of the realtek devices in windows (I will attach files named Enable and Disable). I then wrote a script to pull out the CORB[x] lines from the log and to produce a new script with all the mapped HDA Verbs. This generated 2034 HDA Verb commands (just on the re-enable of the windows realtek device... yikes... ) - Anyway, I ran the script of 2034 HDA Verb commands on my PC. No errors, but unfortunately no sounds came out of the speakers. Very likely I just mapped the values to my HDA verbs incorrectly, I am just guessing on how to do that, or possibly the specific action we need does not happen on a re-enable. Anyway, thoughts? Do you have any more clarity on how to replay the CORB commands? I can try this all again with a suspend and resume, but suspect that will be a lot of CORB values....