On 2012-05-03 11:15, Gerd Hoffmann wrote: > 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.
I measured userspace exists from the kernel. So the VCPU went through the process of taking our Big QEMU Lock, at least 2000 times per second. > >> 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. Then our problem may also lie elsewhere in the audio path. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
