At Tue, 24 Feb 2009 20:26:11 +0100, Lennart Poettering wrote:
On Tue, 24.02.09 19:59, Takashi Iwai (tiwai@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