[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [HACK] hda: expose microphone instead of line-in
From: |
Gerd Hoffmann |
Subject: |
Re: [Qemu-devel] [HACK] hda: expose microphone instead of line-in |
Date: |
Thu, 03 May 2012 16:15:38 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:10.0.4) Gecko/20120422 Thunderbird/10.0.4 |
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