[alsa-devel] [PATCH 2/6] ASoC/mpc5200: get rid of the appl_ptr tracking nonsense

Mark Brown broonie at opensource.wolfsonmicro.com
Thu Nov 12 13:10:34 CET 2009

On Wed, Nov 11, 2009 at 06:13:25PM -0500, Jon Smirl wrote:

> I don't think it is that much more work for ALSA to provide an
> accessible field indicating the end of valid data. It's already
> tracking appl_ptr. Appl_ptr just needs to be translated into a
> physical DMA buffer address and we've been making mistakes doing that
> translation.

I'm sure if you provide reasonable patches they'll get applied; it
doesn't seem likely that anyone else will work on this.

> On Wed, Nov 11, 2009 at 4:57 PM, Grant Likely <grant.likely at secretlab.ca> wrote

> > But it still wouldn't help a bit when the same latency occurs in the
> > middle of playback.

> The deterministic solution of tracking the end of valid data ensures
> that under run will be silent instead of playing invalid data.

In the middle of playback a sudden silence period is very noticable -
applications that expect data loss generally have some means to try to
cover it up since sudden silence is so noticable to the human ear.  Mid
playback there's a bit more chance that random data from earlier in the
playback will be acceptable, and if the application has actually updated
the data but not got round to telling the driver about that yet then
even better.

I think you're getting too focused on the fact that there is a race
condition here since the consequences of race conditions are usually so
severe.  There's always going to be some hardware for which there's a
degree of racyness (free running hardware has its own set of issues
here) so the system design takes this into account.

More information about the Alsa-devel mailing list