From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:52441) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SPwQ7-0004JL-IM for qemu-devel@nongnu.org; Thu, 03 May 2012 09:50:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SPwQ0-0002b9-Tz for qemu-devel@nongnu.org; Thu, 03 May 2012 09:50:11 -0400 Received: from david.siemens.de ([192.35.17.14]:16966) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SPwQ0-0002VH-Jp for qemu-devel@nongnu.org; Thu, 03 May 2012 09:50:04 -0400 Message-ID: <4FA28D06.1070202@siemens.com> Date: Thu, 03 May 2012 10:49:58 -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> <4FA27A24.7050106@siemens.com> <4B275D58-030B-42E1-93A4-77CC849744D0@suse.de> In-Reply-To: <4B275D58-030B-42E1-93A4-77CC849744D0@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-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