Re: [PATCH] ALSA: pcm - introduce soc_delay

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

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

On Mon, Jul 23, 2012 at 04:36:18PM +0530, Vinod Koul wrote:
> On Mon, 2012-07-23 at 11:47 +0100, Mark Brown wrote:

> > 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.

> yes there would be overrun but that is correct one. At that point I can
> see that the DSP would have rendered everything it has (all buffers
> exhausted). At this point app_pointer = hw_pointer and soc_delay would
> be zero.

> I am assuming dsp driver reports the soc_delay dynamically as it would
> do for hw_pointer.

This is sounding exactly like the existing delay parameter and how it's
handled in ASoC.

> This doesn't stop all underruns, they would still be reported.

> This only prevents false underrun when DSP still has something to
> process and give to output DMA.

I don't think you're quite getting my point here.  The DSP still has
something to process but unless whatever is feeding the data to the DSP
stops sending data to the DSP when it catches up with where the
application is writing then there will still be a glitch.

Reporting the delay is useful anyway but it's not the whole picture as
far as recovering from and masking the underrun is concerned.

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

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