On Wed, Nov 11, 2009 at 2:24 PM, Grant Likely <grant.lik...@secretlab.ca> wrote: > On Wed, Nov 11, 2009 at 11:37 AM, Mark Brown > <broo...@opensource.wolfsonmicro.com> 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 equivalent >>> > race where the application has initialized some data but not yet managed >>> > to update the driver to tell it it's being handed over; if the driver >> >>> That's an under run condition. >> >> Yes, of course - the issue is that this approach encourages them, making >> the system less robust if things are on the edge. The 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. With it enabled, I hear the > problem every time. The 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. 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. The dev_dbg() aggravates the race until it is obviously visible every time. A deterministic solution would not be impacted by the dev_dbg(). Implementing a deterministic solution requires support from ALSA core. -- Jon Smirl jonsm...@gmail.com _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
