From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:40880) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SPwoz-0002XF-FD for qemu-devel@nongnu.org; Thu, 03 May 2012 10:15:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SPwop-00056B-C0 for qemu-devel@nongnu.org; Thu, 03 May 2012 10:15:53 -0400 Received: from mx1.redhat.com ([209.132.183.28]:39646) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SPwoo-000562-OU for qemu-devel@nongnu.org; Thu, 03 May 2012 10:15:42 -0400 Message-ID: <4FA2930A.1020804@redhat.com> Date: Thu, 03 May 2012 16:15:38 +0200 From: Gerd Hoffmann 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> <4FA28D06.1070202@siemens.com> In-Reply-To: <4FA28D06.1070202@siemens.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: Jan Kiszka Cc: Alexander Graf , qemu-devel Hi, >>> 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. No. Whatever the qemu iothread is doing does *not* disturb the vcpu(s), as long as they don't need the qemu mutex. And with pt windows can play sound without needing the qemu mutex, whereas with emulation it is needed. > 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? Yes, half buffer. one page buffersize -> 20ms sound data total -> irq & refill every 10ms -> 100 irqs/s needed. Windows uses the same buffer size in passthrough case. cheers, Gerd