On 11 Nov 2009, at 19:24, 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.
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.
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
