[alsa-devel] Timer instability
mznyfn at 0pointer.de
Tue Feb 24 22:16:21 CET 2009
On Tue, 24.02.09 20:26, Lennart Poettering (mznyfn at 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 Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
More information about the Alsa-devel