On Mon, 2012-07-23 at 11:18 +0100, Mark Brown wrote:
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.
having DMA know where app_pointer helps in detection of overrun in dsp. But that's a separate topic.
Take the case of a DSP which employs DMA on input and output (of the DSP) At start, DSP would buffer some data, assuming a period. And assume app has filed one period only. So at start as we buffered a period, ALSA threw up wrong xrun, as it wasn't aware that this buffer is not yet rendered.
Using this notion, ALSA knows that there is some buffer in DSP and used that for xrun as well as delay calculations.
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.
I am not good with names, perhaps soc_buffer is good name :-) ?