@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 :
[email protected]:vfio_region_write (0000:00:1f.3:region0+0x48, 0xad, 2)
[email protected]:vfio_region_write (0000:00:1f.3:region0+0x20,
0x40000000, 4)
[email protected]:vfio_region_write (0000:00:1f.3:region0+0x5d, 0x1, 1)
I get more information, like this :
[email protected]: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
[email protected]: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)
[email protected]: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....
** Attachment added: "CORB"
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1851518/+attachment/5404231/+files/CORB
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1851518
Title:
[950SBE/951SBE, Realtek ALC298, Speaker, Internal] No sound on
internal speakers, very very quiet on headphones
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1851518/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
