[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


>>> 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]