On Mon, Jul 23, 2012 at 03:36:37PM +0530, Vinod Koul wrote:
In many modern SoCs the audio DSP can buffer the PCM ring buffer data. Today we
This isn't particularly new, we've had SRAM buffers in SoCs for ages.
have no means to represent this buffering and ALSA wrongly detects an overrun when hw_ptr reaches app_ptr value, though DSP may still have some buffered data.
It's not immediately clear to me that we shouldn't be flagging an overrun here - obviously if there's just a pure delay introduced by the DSP then we will underrun if we catch up with the input, it's just that there will be a delay in the user hearing it. It seems like the thing we need to say here is more that the DSP or DMA knows where the application pointer is and can halt the DMA when it underruns, together with the fact that we have some buffering beyond the application visible DMA which means that an underrun isn't (yet) a user audible problem. We'd also want some other way of saying that that these further buffers did overrun.
This patch tries to add a new field "soc_delay" to represent buffering done in DSPs. This value is also used for the xrun calculations in ALSA.
soc_delay seems like a very unclear name for this.