From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:35699) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S7mhu-0004Ye-W7 for qemu-devel@nongnu.org; Wed, 14 Mar 2012 07:49:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S7mhq-0007Fl-7e for qemu-devel@nongnu.org; Wed, 14 Mar 2012 07:49:30 -0400 Received: from mx1.redhat.com ([209.132.183.28]:56435) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S7mhp-0007Ff-Vy for qemu-devel@nongnu.org; Wed, 14 Mar 2012 07:49:26 -0400 Message-ID: <4F6085B9.8030008@redhat.com> Date: Wed, 14 Mar 2012 12:49:13 +0100 From: Gerd Hoffmann MIME-Version: 1.0 References: <1331652059-10090-1-git-send-email-marcandre.lureau@redhat.com> <1331652059-10090-12-git-send-email-marcandre.lureau@redhat.com> <4F606350.4050807@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH v4 11/11] audio/rfc: remove PLIVE and PERIOD options List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?ISO-8859-1?Q?Marc-Andr=E9_Lureau?= Cc: dnb@redhat.com, Jan Kiszka , dlaor@redhat.com, qemu-devel@nongnu.org, =?ISO-8859-1?Q?Marc-Andr=E9_Lureau?= On 03/14/12 12:20, Marc-Andr=E9 Lureau wrote: > Hi >=20 > On Wed, Mar 14, 2012 at 10:22 AM, Gerd Hoffmann wro= te: >> On 03/13/12 16:47, malc wrote: >>> On Tue, 13 Mar 2012, Marc-Andr? Lureau wrote: >>> >>>> - period seems to be unused now >> >>> Period on the other hand is unused because i somehow missed the subtl= e >>> change of behavior in one of the patches made by, i think, Gerd. >> >> Uhm, which patch? I think that wasn't intentional, at least I can't >> remember intentionally disabling period. Maybe I missed the subtle >> change of behavior too. >=20 > Could be: >=20 > 39deb1e496de81957167daebf5cf5d1fbd5e47c2 Yes, looks like this one is it. >> I do see the point in having this configurable as this is a cpu overhe= ad >> vs. latency tradeoff which one might want to tweak depending on the us= e >> case. >=20 > But that would impact a/v sync, or can you report added latency back > to the guest somehow? I imagine audio backend latency should depend on > the configured device buffering/latency, not on an environment tweak. Sure, with lower latency you get better a/v sync too. Guest interfacing is next to impossible I think, simply because real hardware has no need for that and thus the interfaces simply don't exist in the hardware we are emulating. We can try to fix that with a virtio soundcard which has such interfaces, but it could be this simply shifts the issue from the driver/hardware interface to the os-kernel/driver interface. cheers, Gerd