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.