[alsa-devel] [PATCH] ALSA: pcm - introduce soc_delay
vinod.koul at linux.intel.com
Mon Jul 23 13:14:12 CEST 2012
On Mon, 2012-07-23 at 12:47 +0200, Jaroslav Kysela wrote:
> mm, it's confusing to have both delay and soc_delay fields.
> > And, if the XRUN detection is the only problem, we can provide a flag
> > to correct avail with runtime->delay.
> I agree. The runtime->delay variable should handle all situations for
> queued samples.
> But the point is - we have data in some FIFO, but the DMA ring buffer is
In a DSP you can have input buffer (from the ring buffer), which is post
processed and sent to output DMA buffer. This buffering is dynamic in
nature and since input buffer is memory copy, it would buffer ahead of
time unlike the output buffer which will run at PCM rate. The samples at
input DMA and various modules doing DSP processing are still before
output circular DMA and should be considered when we do xrun
> If you use the delay value in the snd_pcm_update_state(), you'll
> probably allow to transfer invalid samples to the FIFO (probably
> previous samples from the ring buffer, because application has not
> provided new ones). That was the purpose of the check.
Yes and the right one. But what about samples still there before DMA,
this patch just attempts to represent those. not the ones at and after
DMA, they are correctly represented today in runtime->delay.
> Of course, if you stop DMA according the appl_ptr and wait on
> application to provide new data in the "FIFO time window", then the
> check should be updated for this type of hw.
More information about the Alsa-devel