[alsa-devel] Timer instability
Lennart Poettering
mznyfn at 0pointer.de
Mon Feb 23 03:56:10 CET 2009
On Mon, 23.02.09 03:42, Lennart Poettering (mznyfn at 0pointer.de) wrote:
>
> On Sun, 22.02.09 04:14, Lennart Poettering (mznyfn at 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:
[...]
This is the end of the tool's output for HDA AD1989B:
http://fpaste.org/paste/4240
The device is completely filled up (i.e. avail is 0, delay is 4416)
and then after 2us suddenly the avail jumps to 4971973988617027465 and
the delay to -4971973988617023049.
Smells like an integer overflow to me ...
Hmm, for now my little testing experiment I've now found es1969,
ens1371, intel8x0, snd-emu10k1 and some intel-hda to have unreliable
_avail() or _delay().
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
More information about the Alsa-devel
mailing list