From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33276) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZtFUd-0006vA-8T for qemu-devel@nongnu.org; Mon, 02 Nov 2015 08:49:51 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZtFUZ-0000yX-7Z for qemu-devel@nongnu.org; Mon, 02 Nov 2015 08:49:51 -0500 Received: from mx1.redhat.com ([209.132.183.28]:54817) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZtFUZ-0000y8-1j for qemu-devel@nongnu.org; Mon, 02 Nov 2015 08:49:47 -0500 Message-ID: <1446472183.7412.52.camel@redhat.com> From: Gerd Hoffmann Date: Mon, 02 Nov 2015 14:49:43 +0100 In-Reply-To: <20151102130749.GA10139@stefanha-x1.localdomain> References: <8AEDA8BB-5138-47AF-98B7-D8E5BCE0E1FB@gmail.com> <20151016121548.GH10205@stefanha-thinkpad.redhat.com> <78B63DA5-2230-4ECA-8F06-EC81F677895C@gmail.com> <20151026110054.GF20111@stefanha-x1.localdomain> <1445862240.4397.29.camel@redhat.com> <20151028105856.GA2520@stefanha-x1.localdomain> <0AEC420D-E0AB-4D80-81F0-D41A0D27985A@gmail.com> <20151029150818.GC5466@stefanha-x1.localdomain> <4D46C0B4-B015-4C55-8126-CCF80999C0ED@gmail.com> <1446202769.1144.25.camel@redhat.com> <20151102130749.GA10139@stefanha-x1.localdomain> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] hw/usb/dev-audio.c: make USB audio card sound perfect List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: Programmingkid , "H. Peter Anvin" , qemu-devel qemu-devel , spice-devel Hi, > > Higher chance is with video playback. lip sync issues might show up, > > although you probably still have to watch carefully to actually notice. > > Regarding the video playback workload: video playback is not a > low-latency audio use case. That's why you won't notice any difference > if the USB audio device has a larger buffer size. Well, yes, it isn't low-latency indeed, but probably still sensitive to the buffer size. The buffer we are talking about here is a pure host-side thing, the guest doesn't know it exists and how big it is. > This can be implemented with large audio buffers, Yes, but for that the player needs to know how big the buffer is so the audio clock math is correct ... cheers, Gerd