On Tue, 24.02.09 20:26, Lennart Poettering (mznyfn@xxxxxxxxxxx) 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 -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
