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: Wed, 02 May 2012 15:17:07 -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-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?

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]