From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:39217) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TB02a-0001Q4-4E for qemu-devel@nongnu.org; Mon, 10 Sep 2012 05:12:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TB02P-0004qt-HU for qemu-devel@nongnu.org; Mon, 10 Sep 2012 05:12:24 -0400 Received: from mx1.redhat.com ([209.132.183.28]:26702) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TB02P-0004qg-8u for qemu-devel@nongnu.org; Mon, 10 Sep 2012 05:12:13 -0400 Message-ID: <504DAEE1.7060603@redhat.com> Date: Mon, 10 Sep 2012 12:12:01 +0300 From: Avi Kivity MIME-Version: 1.0 References: <504A1C35.5070809@lotspeich.org> <504B23BB.2080407@web.de> <504CACA2.7050203@redhat.com> <504DADA6.7090406@web.de> In-Reply-To: <504DADA6.7090406@web.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Linux KVM, Windows 7 guest choppy sound List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: Erik Lotspeich , qemu-devel@nongnu.org On 09/10/2012 12:06 PM, Jan Kiszka wrote: >>> Known issue, likely unfixable in QEMU due to hard-coded constraints of >>> the driver Windows uses (too small playback buffers). >> >> Would using real-time priority for the guest improve things? >> >> Of course that can be dangerous if the guest decides to spin and has as >> many vcpus as you have cores. > > We need to decouple the data path of that device from the rest of QEMU > first. Just prioritizing likely doesn't help. Depends on what the guest is doing, but likely you are right. Luckily we're already doing that. > And then the problem might > be getting sufficient reactivity from the QEMU-external audio data path > as well. Those already have realtime priority. Doesn't guarantee the path is short enough but it may work. -- error compiling committee.c: too many arguments to function