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

[Jan Kiszka]

On 2012-05-03 09:42, Alexander Graf wrote:
> 
> On 03.05.2012, at 14:29, Jan Kiszka wrote:
> 
>> On 2012-05-02 19:42, Alexander Graf wrote:
>>>
>>> On 02.05.2012, at 20:17, Jan Kiszka wrote:
>>>
>>>> On 2012-04-25 09:34, Gerd Hoffmann wrote:
>>>>> On 04/25/12 13:03, Jan Kiszka wrote:
>>>>>> Hi Gerd,
>>>>>>
>>>>>> I had problems with Windows LiveMeeting expecting a microphone as
>>>>>> input. But the HDA model only exposes a line-in port. The following hack
>>>>>> works for me, but I bet there is a cleaner solution. Any suggestions?
>>>>>
>>>>> Good to know this works.  /me has patches ready to go, was just waiting
>>>>> for testing feedback ...
>>>>>
>>>>> Pushed to git://git.kraxel.org/qemu audio.1
>>>>>
>>>>> They do essentially the same, except that they leave the existing
>>>>> hda-duplex code as-is and add a new hda-micro codec instead which
>>>>> advertises the input as micro to the guest.
>>>>
>>>> Yep, would work fine - if the issue below allowed me to use it.
>>>>
>>>>>
>>>>>> BTW, sound output quality of a Win7 guest on my Linux hosts sucks while
>>>>>> it's fine for a Linux guest. I vaguely recall that Windows requests a
>>>>>> too small DAC buffer, is that true? Is there anything one can do about
>>>>>> this?
>>>>>
>>>>> Yes.  The buffer is ~ one page and can hold 20 ms of sound data, so
>>>>> considering buffer flipping intel-hda has to shuffle data every 10ms,
>>>>> and the windows guest needs to be scheduled too so it can re-fill the
>>>>> other half of the buffer.  Which obviously makes sound playback *very*
>>>>> sensitive to latencies anywhere in the qemu.
>>>>>
>>>>> What you can do about it?  Dunno whenever windows allows to tweak the
>>>>> buffer size somehow.  When I looked deeper at that a while back the
>>>>> biggest latency issues in qemu used to be qxl, ide/qcow2 and vnc.  qcow2
>>>>> should be fixed now with the switch to coroutines and full async i/o.
>>>>> Likewise qxl, although this depends on recent guest drivers.  For vnc
>>>>> enabling the threaded vnc server helps alot (without it moving around
>>>>> windows leads to sound dropouts).
>>>>
>>>> I found another workaround: audio hw passthrough. Works nicely. And this
>>>> indicates that there should be still some room for improvement in the
>>>> device model so that Windows chooses a proper ring buffer size, no?
>>>
>>> Why? For hw passthrough, mmio doesn't go through qemu anymore, right? :)
>>
>> 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.

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?

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux