[alsa-devel] [PATCH] ALSA: pcm - introduce soc_delay

Vinod Koul vinod.koul at linux.intel.com
Mon Jul 23 13:06:18 CEST 2012


On Mon, 2012-07-23 at 11:47 +0100, Mark Brown wrote:
> 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.
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 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.
> 
> > > > 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.
Hmmm, yes this can happen outside soc's as well. dsp_buffer is my next
candidate :)


-- 
~Vinod



More information about the Alsa-devel mailing list