On Tue, 24.02.09 20:26, Lennart Poettering (mznyfn@0pointer.de) wrote:
Oh, and one thing I didn't actually notice earlier: Most drivers return a negative snd_pcm_delay() if a real underrun happens. According to the definition of snd_pcm_delay() that we agreed on a couple of months ago and that is now docuemented in doxygen this makes no sense. The definition of snd_pcm_delay() goes like this:
"For playback the delay is defined as the time that a frame that is written to the PCM stream shortly after this call will take to be actually audible. It is as such the overall latency from the write call to the final DAC." (from the doxygen docs)
I.e. because on the this world it is impossible to hear a sample that hasn't even been written yet, _delay() should only return positive values. However many drivers do return negative values on underrun.
I take this back.
I think the correct way to handle an underrun when stop_threshold is set to boundary is that if a write happens after an underrun the appropriate amount of data is simply dropped. I think enabling this mode is primarily useful to guarantee timer stability even in case of underrun. That means snd_pcm_delay() should very well return negative values meaning "what you write next is past the playback pointer, it will not be heard".
Lennart