From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:52615) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SPe75-0007mg-1X for qemu-devel@nongnu.org; Wed, 02 May 2012 14:17:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SPe6z-0004RU-4j for qemu-devel@nongnu.org; Wed, 02 May 2012 14:17:18 -0400 Received: from goliath.siemens.de ([192.35.17.28]:18460) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SPe6y-0004RB-RE for qemu-devel@nongnu.org; Wed, 02 May 2012 14:17:13 -0400 Message-ID: <4FA17A23.1060502@siemens.com> Date: Wed, 02 May 2012 15:17:07 -0300 From: Jan Kiszka MIME-Version: 1.0 References: <4F97D9E4.7090608@siemens.com> <4F97EF39.8080207@redhat.com> In-Reply-To: <4F97EF39.8080207@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [HACK] hda: expose microphone instead of line-in List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: qemu-devel 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