Re: [PATCH] ALSA: pcm - introduce soc_delay

[Mark Brown <broonie@opensource.wolfsonmicro.com>]

[-- Attachment #1.1: Type: text/plain, Size: 1327 bytes --]

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.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]