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

[Jan Kiszka <jan.kiszka@siemens.com>]

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