Date 23.7.2012 12:27, Takashi Iwai wrote:
At Mon, 23 Jul 2012 15:36:37 +0530, Vinod Koul wrote:
In many modern SoCs the audio DSP can buffer the PCM ring buffer data. Today we 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.
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.
Signed-off-by: Vinod Koul vinod.koul@linux.intel.com
-- Once we are okay with this approach, I will send a follow up patch which adds this notion in ASoC and uses this to compute cpu_dai delay. The codec_dai delay along with FIFO delay from cpu_dai should be added and reresented by today's notion of delay.
Hmm, 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 empty. 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.
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.
Jaroslav