[alsa-devel] Timer instability

[Takashi Iwai]

At Tue, 24 Feb 2009 22:16:21 +0100,
Lennart Poettering wrote:
> 
> 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".

Well, I'm afraid that it's undesired behavior.

In a free-wheel mode, there is no real underrun (except that the
driver pointer callback explicitly returns the error).  It basically
means "I do care any XRUN errors by myself, so don't bother me no
matter what crazy value is set."  PCM core shouldn't react so much
differently depending on the avail/delay value in this mode.

Anyway, the definitions of delay and avail in a free-wheel mode are
ambiguous and rather confusing indeed...


Takashi