On 11 Nov 2009, at 19:24, Grant Likely <grant.likely@xxxxxxxxxxxx> wrote: > On Wed, Nov 11, 2009 at 11:37 AM, Mark Brown > <broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx> 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. Yes, that does sound entirely consistent with the problem being a latency issue if you're sending the dev_dbg() output to the serial port. I'd be surprised if it were anything else to be honest. _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel