From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:42515) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SPx3o-0006iz-Gq for qemu-devel@nongnu.org; Thu, 03 May 2012 10:31:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SPx3f-0002fH-7G for qemu-devel@nongnu.org; Thu, 03 May 2012 10:31:12 -0400 Received: from goliath.siemens.de ([192.35.17.28]:32923) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SPx3e-0002ej-Te for qemu-devel@nongnu.org; Thu, 03 May 2012 10:31:03 -0400 Message-ID: <4FA296A0.5070706@siemens.com> Date: Thu, 03 May 2012 11:30:56 -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> <4FA28D06.1070202@siemens.com> <4FA2930A.1020804@redhat.com> In-Reply-To: <4FA2930A.1020804@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: Alexander Graf , qemu-devel On 2012-05-03 11:15, Gerd Hoffmann wrote: > 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. I measured userspace exists from the kernel. So the VCPU went through the process of taking our Big QEMU Lock, at least 2000 times per second. > >> 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. Then our problem may also lie elsewhere in the audio path. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux