Re: [PATCH] ALSA: pcm - introduce soc_delay

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

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

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.

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

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