Re: [Qemu-devel] [HACK] hda: expose microphone instead of line-in

[Gerd Hoffmann]

  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