[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: Jan Kiszka
Subject: Re: [Qemu-devel] [HACK] hda: expose microphone instead of line-in
Date: Thu, 03 May 2012 09:29:24 -0300
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv: Gecko/20080226 SUSE/ Thunderbird/ Mnenhy/

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.


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]