From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:52162) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SPvA9-0002W1-93 for qemu-devel@nongnu.org; Thu, 03 May 2012 08:29:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SPvA3-0001AD-VM for qemu-devel@nongnu.org; Thu, 03 May 2012 08:29:36 -0400 Received: from david.siemens.de ([192.35.17.14]:20418) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SPvA3-00017G-Lq for qemu-devel@nongnu.org; Thu, 03 May 2012 08:29:31 -0400 Message-ID: <4FA27A24.7050106@siemens.com> Date: Thu, 03 May 2012 09:29:24 -0300 From: Jan Kiszka MIME-Version: 1.0 References: <4F97D9E4.7090608@siemens.com> <4F97EF39.8080207@redhat.com> <4FA17A23.1060502@siemens.com> <4927FF2E-FF9A-4DDE-A6F0-3822515998F8@suse.de> In-Reply-To: <4927FF2E-FF9A-4DDE-A6F0-3822515998F8@suse.de> 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: Alexander Graf Cc: Gerd Hoffmann , qemu-devel 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. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux