[alsa-devel] Timer instability
mznyfn at 0pointer.de
Wed Feb 25 11:44:21 CET 2009
On Wed, 25.02.09 11:08, Takashi Iwai (tiwai at suse.de) wrote:
> At Tue, 24 Feb 2009 21:37:20 +0100,
> I wrote:
> > > stop_threshold is completely irrelevant to the problems discussed
> > > here.
> > OK, but let me continue that tomorrow or later.
> Running it with five sound cards (two HD-audio, emu10k1, CMI8738, and
> envy24HT) overnight with tail -500, but nothing appears on my
> All outputs look OK: the first three columns are almost same values,
> avail is a few (< 10), delay is about the buffer size.
> How can you trigger the problem so easily?
Hmm, that's a good question. It's not just me btw who can reproduce
this that easily. I have put up a page (see bottom of
http://pulseaudio.org/wiki/BrokenSoundDrivers) for this tool during
the WE and got about 20 reports back (some of this I actually
mentioned on the ML already), for different cards on different distros
(from all of Fedora, OpenSUSE, Mandriva, Ubuntu and Debian).
Most of this issues can be reproduced in 5 mins or so. For the
intel8x0 issues it was a little bit harder, took 30min to be triggered.
Most of my own tests was one SMP btw, not sure if that matters. The
excpetion is the intl8x0 stuff which I tested in a machine with a
Since a few PA versions back I write into syslog when snd_pcm_avail()
returns apparently overflown values. Our bugzilla is now full of
reports of messages like this. Here are a two of them as examples:
(Look for the snd_pcm_avail_update() log messages in those reports)
BTW, any update on the issue that calling poll() on an ALSA device
returns POLLOUT however a subsequent snd_pcm_avail() returns 0 or some
other value < min_avail? I reported that a while back on the ML. And a
*lot* of drivers are suffering by this. This causes the PA IO loop
to spin quite often for no reason.
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
More information about the Alsa-devel