[alsa-devel] Timer instability
tiwai at suse.de
Tue Feb 24 21:37:20 CET 2009
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
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
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
More information about the Alsa-devel