[alsa-devel] Timer instability

[Takashi Iwai]

At Tue, 24 Feb 2009 20:26:11 +0100,
Lennart Poettering wrote:
> 
> On Tue, 24.02.09 19:59, Takashi Iwai (tiwai at suse.de) wrote:
> 
> > > Yes, threshold is set to boundary. But that's intended. Remember that
> > > the original purpose of the tool is to graph _avail() and _delay()
> > > against the time. For that I want to make sure the that timing stays
> > > stable no matter what.
> > > 
> > > In reality this setting should not matter at all, because most machines
> > > should be fast enough to keep the buffer filled even if we write one
> > > sample at a time as it is done in the example.
> > 
> > Not really.  If you feed the output to a terminal, it's damn slow.
> > That's why I got XRUN.
> 
> Oh, of course, I should have mentioned that.
> 
> The tool generates a *lot* of data, given that it queries _avail() and
> _delay() in a busy loop.
> 
> To run it either redirect the output to disk (which of course might
> create gaps in the output if we write faster than the disk can take it
> but this is easily detected by looking on the first column). Or
> pipe it directly to something like "tail -n 50".

Damn, you should have mentioned it before.  I lost too long time
just for that!

> > > In summary: just ignore the setting of the stop threshold. It is not
> > > related to the problems exposed here.
> > 
> > FWIW, when I run the program and feed the output to /dev/null, I don't
> > get abort() after minutes.  It happened soon only when it runs on a
> > terminal.  So, the condition appears very likely as an XRUN.
> 
> The outputs I posted earlier are *not* due to normal underruns. Please
> have a look at the actual data!

I didn't get any "actual data" because of xrun.

> > So, try to set stop_threshold to buffer_size once, and check whether
> > you get any different result.  Let's check another possibility if it
> > really isn't the case.
> 
> In those test cases no normal XRUN ever happens unless you pipe the
> output to a terminal: please, just actaully look at the data
> generated!

The data isn't generated if XRUN occurs because it stops with
assert() at that point.

> The effective difference for this tool that it makes to set
> stop_threshold to boundary or not is simply this:
> 
>     if stop_threshold is set to boundary underruns will be caught by the
>     mentioned assert.
> 
>     if stop_threshold is not set to boundary underruns result in an EPIPE
>     which is then caught by a different assert in the code.
> 
> So again: how stop_threshold is set is *irrelevant* for the test case!

But the assert caught exaclty the XRUN.  Not *always* irrelevant.

> It simply would cause a different assert() to be triggered! That is
> all. And again, unless you machine is very slow or otherwise busy
> _avail() should never come near the buffer size except very early
> afetr startup.

It came.  Maybe it's slow.

> stop_threshold is completely irrelevant to the problems discussed
> here.

OK, but let me continue that tomorrow or later.

> 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.

Maybe you are walking faster than the light speed.

I don't mind to add a negative check in the delay value, but who would
actually care?  It's underrun, so the behavior of the hardware isn't
really defined...


Takashi