At Tue, 24 Feb 2009 20:26:11 +0100, Lennart Poettering wrote: > > On Tue, 24.02.09 19:59, Takashi Iwai (tiwai@xxxxxxx) 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 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
