ALC3306 debugging - QemuHDADump issues

[camberkenpas]

I emailed this first and then realized this was probably the right place to bring this to attention.

I'm trying to debug sound on my Lenovo Legion laptop (headphones work fine, speakers do not). It's using the ALC3306 (though internally the vendor ID suggests that it's an ALC287).

I'm pretty new to this process, but I've been attempting to run a Windows 10 VM through qemu while piping through to your QemuHDADump program.

I'm able to get sound from my speakers via the virtual machine, and I do get frame files... However, while I always get frame0000, I never get frame00001, I get either frame0003, frame0004, or even frame0005 once.

Could it be that the frames generated with the sound hardware are causing frame numbers to be incremented prematurely? Would that mean that my hardware is resulting in a use case that QemuHDADump doesn't quite know how to handle? However, looking through QemuHDADump.c, frame_cnt is only incremented in one place and it's after a write.

ExtractHDADump fails with a double free in the case of non-sequential frame files. If I rename the next frame (from say frame0004) to frame0002, ExtractHDADump appears to complete (although I'm unsure what to do with all-corb-frames and all-rirb-frames).

Is it okay to just rename the frame files so they're in sequence? Ie, 0001, 0002, ..., 000n? Or is that breaking things? Here's the stdout from ExtractHDADump if I do this:

frame_cnt 1.

[camberkenpas]

I've done a little debugging, and many frames are being dumped to disk as "exit frames. In particular, this section:

        switch (data->bar_addr) {
        case 0x20:
                if ((data->bar_data & 0x40000000) && (data->corb_cnt > 20))
                        dump_current_frame(data, 1);

                break;

There's multiple dumps for frame0001, but they're always all exist frames. Most/all the other frames are written to disk many times as exist frames and occasionally we get "lucky" and we get a "normal" dump so we move on to the next frame.

For example, we get to frame count 4, and we have multiple writes at that frame count as "exit_frame", we finally get a different bar address and finally frame0004 is written to disk and frame_cnt is incremented.

I suspect this behavior is not expected. I wish I knew more about the bar address (I know nothing). Unfortunately, I know so little about what's going on here, I don't even know what to start searching for. :)