On Wed, Nov 11, 2009 at 2:24 PM, Grant Likely grant.likely@secretlab.ca wrote:
On Wed, Nov 11, 2009 at 11:37 AM, Mark Brown broonie@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.