From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yx0-f179.google.com (mail-yx0-f179.google.com [209.85.210.179]) by ozlabs.org (Postfix) with ESMTP id 1A8C8B7088 for ; Thu, 12 Nov 2009 08:57:41 +1100 (EST) Received: by yxe9 with SMTP id 9so1702326yxe.26 for ; Wed, 11 Nov 2009 13:57:39 -0800 (PST) MIME-Version: 1.0 Sender: glikely@secretlab.ca In-Reply-To: <9e4733910911111334o24f3114as6baaef82d7b17a05@mail.gmail.com> References: <20091107081631.18908.82921.stgit@angua> <20091107083358.18908.10635.stgit@angua> <9e4733910911070451y28073dbeke6ced6246f5a5c24@mail.gmail.com> <20091107201233.GC31789@sirena.org.uk> <9e4733910911110838w6010cf3atcfcd30c85f0764a1@mail.gmail.com> <20091111183753.GA31815@rakim.wolfsonmicro.main> <9e4733910911111334o24f3114as6baaef82d7b17a05@mail.gmail.com> From: Grant Likely Date: Wed, 11 Nov 2009 14:57:19 -0700 Message-ID: Subject: Re: [alsa-devel] [PATCH 2/6] ASoC/mpc5200: get rid of the appl_ptr tracking nonsense To: Jon Smirl Content-Type: text/plain; charset=ISO-8859-1 Cc: John Bonesio , alsa-devel@alsa-project.org, Mark Brown , linuxppc-dev@lists.ozlabs.org, lrg@slimlogic.co.uk List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Wed, Nov 11, 2009 at 2:34 PM, Jon Smirl wrote: > On Wed, Nov 11, 2009 at 2:24 PM, Grant Likely = wrote: >> On Wed, Nov 11, 2009 at 11:37 AM, Mark Brown >> wrote: >>> On Wed, Nov 11, 2009 at 11:38:06AM -0500, Jon Smirl wrote: >>>> > Providing a final valid data point to the driver would possibly even >>>> > make things worse since if it were used then you'd have the equivale= nt >>>> > race where the application has initialized some data but not yet man= aged >>>> > to update the driver to tell it it's being handed over; if the drive= r >>> >>>> That's an under run condition. >>> >>> Yes, of course - the issue is that this approach encourages them, makin= g >>> the system less robust if things are on the edge. =A0The mpc5200 seems = to >>> be not just on the edge but comfortably beyond it for some reason. >> >> I can't reproduce the issue at all as long at the dev_dbg() statement >> in the trigger stop path is disabled. =A0With it enabled, I hear the >> problem every time. =A0The 5200 may not be a speedy beast, but it is >> plenty fast enough to shut down the audio stream before stale data >> starts getting played out. > > "fast enough" - you just said it is a race. > I've been saying it is a race too. Yes, it is a race; but not the kind that is dangerous. Audio playout is always a real-time problem; whether in the middle of a stream or at the end. If the CPU gets nailed with an unbounded latency, then there will be audible artifacts - Regardless of whether the driver knows where the end of data is or not. If it does know, then audio will stutter. If it doesn't know, then there will be repeated samples. Both are nasty to the human ear. So, making the driver do extra work to keep the extra data in sync will probably force larger minimum latencies for playout (trouble for VoIP apps) so the CPU can keep up, and won't help one iota for making audio better. The real solution is to fix the worst case latencies. > There are two options: > 1) Eliminate the race by developing a system to deterministically flag > the end of valid data. > 2) Fudge everything around making it almost impossible to lose the > race, but the race is still there. 3) eliminate the unbounded latencies (fix the PSC driver and/or use a real time kernel) 4) make sure userspace fills all the periods with silence before triggering stop. Gstreamer seems to already do this. I suspect pulseaudio does the same. > The dev_dbg() aggravates the race until it is obviously visible every > time. A deterministic solution would not be impacted by the dev_dbg(). But it still wouldn't help a bit when the same latency occurs in the middle of playback. g. --=20 Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd.