On Mon, Jul 23, 2012 at 04:09:06PM +0530, Vinod Koul wrote:
On Mon, 2012-07-23 at 11:18 +0100, Mark Brown wrote:
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
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.
I'm having a hard time relating this to what I was saying. The point here is that if the device keeps marching on consuming data (as most cyclic DMAs would) then there's still going to be an underrun even if there's a buffer that causes a delay in the user hearing it.
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 :-) ?
The "soc" is the problem here - this shouldn't be specific to some sort of hardware.