Hi, >>> The point is that both pt as well as emulation suffer from the same >>> issue: lacking real-time support of QEMU. So I guess Windows uses a >>> different buffer size for the real hardware than for our HDA model. >> >> For pt hardware, the BARs just get directly mapped into guest memory space, >> so BAR accesses don't go through QEMU anymore. I guess you're also using the >> in-kernel PIC, at which point you're not using QEMU anymore for the HDA. The >> vcpus should keep running even when you move windows in VNC, right? >> >> So it could just as well be that Windows is not using a different buffer >> size, but you're simply exiting into QEMU a lot less, getting better >> latencies. > > That appears like a simple explanation, but I'm basically getting the > same exit rate with emulation as with pt (>2000 userspace exits/s). At > this rate, every significant userspace delay should be audible as it > also delays vcpu execution.
No. Whatever the qemu iothread is doing does *not* disturb the vcpu(s), as long as they don't need the qemu mutex. And with pt windows can play sound without needing the qemu mutex, whereas with emulation it is needed. > The IRQ rate with pt is around 100 HZ. When does the hardware trigger an > IRQ? Likely before the end of the buffer. At half of its size? Yes, half buffer. one page buffersize -> 20ms sound data total -> irq & refill every 10ms -> 100 irqs/s needed. Windows uses the same buffer size in passthrough case. cheers, Gerd
