On Wed, Nov 11, 2009 at 1:37 PM, Mark Brown <broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote: > On Wed, Nov 11, 2009 at 11:38:06AM -0500, Jon Smirl wrote: > >> There are two solutions: >> 1) tell me where the end of the valid data is. That allows me to >> program the hardware to not enqueue the invalid data. >> 2) For batched hardware, pad an extra period with silence after the >> end of the stream. (that what zeroing the buffer before handing it >> back to ALSA > > You've also got the option of lying about where the hardware is in some > form in order to give you more headroom. > > I'm not sure what you mean by "batched hardware" here. SNDRV_PCM_INFO_BATCH Hardware that can't give you the DMA position except at the end of DMA transfers. > >> I believe this race is present in all ALSA drivers. It's just a lot >> harder to hit on different hardware. For example to hit it on Intel >> HDA which is non-batched hardware, the song would need to end right at >> the end of a period. Then the interrupt latency would need to be bad >> enough that some invalid data got played. But x86 CPUs are very fast >> so it is rare for the interrupt latency to be bad enough that the >> stream doesn't get stopped in time. > > The potential is there for this to happen on any hardware, yes. On the > other hand, it's not been a pressing issue elswhere - including on > things like older ARM systems which aren't exactly noted for their > snappy performance. It really does sound like there's something special > going on with these systems that's at least somewhat unique to them. > >> > 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. > -- Jon Smirl jonsmirl@xxxxxxxxx _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
