From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=57713 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PG8zI-0007Bm-6s for qemu-devel@nongnu.org; Wed, 10 Nov 2010 06:37:13 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PG8zH-0006cv-24 for qemu-devel@nongnu.org; Wed, 10 Nov 2010 06:37:12 -0500 Received: from mx1.redhat.com ([209.132.183.28]:55512) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PG8zG-0006co-Q9 for qemu-devel@nongnu.org; Wed, 10 Nov 2010 06:37:11 -0500 Message-ID: <4CDA83E0.1070704@redhat.com> Date: Wed, 10 Nov 2010 12:37:04 +0100 From: Gerd Hoffmann MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH] spice: add audio References: <20101109211021.45EC22A34D@zimbra14-e2.priv.proxad.net> <817F9C5B-1459-444F-9E4D-A06C7420CBC8@free.fr> <4CDA6A77.1050806@redhat.com> <20101110103611.GC11830@redhat.com> In-Reply-To: <20101110103611.GC11830@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: =?ISO-8859-1?Q?Fran=E7ois_Revol?= , qemu-devel@nongnu.org On 11/10/10 11:36, Daniel P. Berrange wrote: > On Wed, Nov 10, 2010 at 10:48:39AM +0100, Gerd Hoffmann wrote: >> The qemu vnc server has support already, and I think Daniel (added to >> Cc:) has some experimental patches for the gtk-vnc widget. > > Yes I do have patches, but I'm yet to get it to work reliably enough for > anyone to use for real. eg any time there are large frambuffer updates > due to, say, dragging a window around, audio will drop out. Until I can > prove that it is even semi-reliable I'm not going to include the code in > gtk-vnc, because I don't want to commit to supporting something that may > well be fundamentally broken/unusable for live audio playback. Do you know where the dropouts come from? I think one issue are latencies within qemu. The qemu vnc server is busy for a while when doing bulky screen updates and blocks other stuff while it runs. I've seen dropouts with vnc + bulky screen updates too. The smaller the audio buffers used by the device/guest are the more visible this effect is. When enabling the threaded vnc server this becomes alot better, did you try that? Another problem might be the outgoing tcp pipeline being flooded with screen updates, leading to high network latencies for the audio data as vnc (unlike spice) sends everything over the same tcp connection. Finally it could be gtk-vnc itself being busy with something and not playing audio in a timely manner (not very likely IMHO). cheers, Gerd