xeyes wrote:once I turn on the interrupt bit, Qemu can clear the accumulated counter and a small number in RINTCNT suffices. Perhaps an edge case that they never noticed/bother to fix.
Nice. Yes, the emulation seems just enough to allow the operating systems to function properly.
---
xeyes wrote:HDA's only AFG claims that it does NOT support 48Khz which is the only sample rate required by the spec
You can set up input amplifier (should not exist) for a DAC and read back the written gain correctly
You can set up input and output amplifier for most pin complexes that claim to contain neither input nor output amp and read back the written gain correctly
For pin complexes that claim EAPD support, trying to turn that on always fail (read back zero again)
I can't comment on the rest of the points, but research on the first one (about 48KHz) shows that some drivers assume (perhaps owing to the authoritative statements in the spec) that the bit rate is indeed supported, regardless of its representation (or its absence) within the PCM parameters.
On FreeBSD, the HDA driver
unconditionally selects 48KHz as available without checking if the 48KHz bit (R7 in the spec) is set within the PCM Capability parameters.
---
VirtualBox does give the reason it doesn't set the 48KHz bit:
Code: Select all
234 /* Note! We do not set CODEC_F00_0A_48KHZ here because we end up with
235 S/PDIF output showing up in windows and it trying to configure
236 streams other than 0 and 4 and stuff going sideways in the
237 stream setup/removal area. */
The emulators seem to take certain liberties with the specs (not only for audio), for faster shipping of the product/feature, for performance reasons, for workarounds like the one above, or due to plain oversight, etc.
VBox emulates a Sigmatel/IDT STAC9220 codec; from the looks of its source, it seems to be quite an extensive support. But, as it is still an emulation, VBox might not follow the spec to the letter.
xeyes wrote:Perhaps better to wait until I have more time to continue the game of guessing who misinterpreted the spec in what way.
Will also try to look around for actual HW that has HDA on a PCI bus (no PCIe support yet).
Before any of these can happen, Qemu is still the dev platform of choice
Working with actual hardware, one can avoid dealing with the idiosyncrasies of an emulation, though it does require a separate machine/SBC/NUC. Another option is the qemu-KVM-vfio-passthrough of the host machine's HDA audio controller device into a VM. One can try attaching the controller as an integrated endpoint to the default
pcie bus of a q35 machine. I think much of the complexity of pcie remains hidden with such a setup, and one gets to program actual hw while still benefitting from the ease of development afforded by VMs.
xeyes wrote:Thanks again for the help, and happy new year!
Happy New Year, and to all as well!