qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Jan Kiszka
Subject: Re: [Qemu-devel] [HACK] hda: expose microphone instead of line-in
Date: Thu, 03 May 2012 11:30:56 -0300
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666

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



reply via email to

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