On Sun, 22.02.09 04:14, Lennart Poettering (mznyfn@0pointer.de) wrote:
I wrote this little test to track down all kinds of timer issues: it opens and sets up a sound device. Then it will constantly query _avail(), _delay() and _htstamp() in a busy loop writing a single sample at a time. The three values are then printed along with a system timestamp. The data generated like this can be opened in gnumeric and a nice graph be drawn.
Hmm, did some more testing with this tool on other cards:
On es1969 snd_pcm_avail() sometimes returns values like 1073728596 samples. This smells a lot like an overflow given that this times four (i.e. the sample size in bytes) is near to 2^32.
Here's an output of this tool for an emu10k1 card:
Check out line 4417: This is when the devcie starts playback. avail goes rightfully to 0 (i.e column 4 -- don't get confused by the line numbers the nopaste adds here), but the playback time suddenly jumps from 100113 us down to 702 us (column 4 which is the written sample counter minus the delay transformed to us). This is because in contrast to most other drivers for this one writing a sample has no direct effect on snd_pcm_delay while the device is stopped.
Also this shows that the data from _avail() and _status() together is not atomic: the columns for avail delay change in different rows when we don't get scheduled often enough.
Lennart