Yes, I use the same stress-test method :-) I have seen your symptoms on
my setup. I call it "ALSA confusion". This happens as a result of
poorly written ALSA plugin code, or hardware which ALSA and/or the
kernel does not understand or work with very well. I found the
following specific causes listed in WWW references:
1. The ALSA Jack plugin. Don't try to use it. It is bad. I saw this
2. Very heavy use of my motherboard sound system with ACPI engaged in
the kernel. I turned off ACPI in the kernel, my latency dived,
performance rose, and ALSA confusion vanished.
3. Sharing an IRQ between the motherboard sound and the video system.
This can be tricky to solve, it can require BIOS changes and/or PCI card
position changes, and is not always possible for motherboard hardware.
Happily, a very good quality PCI implementation should not exhibit this
problem at all. I didn't see this one happen (my motherboard is new),
but read about it a lot in trying to solve my problems.
4. Attempts to write to the same ALSA device by two different apps
simultaneously. On AVLinux this shouldn't be too hard to spot, in many
desktop distro situations it might be considerably more difficult. The
ALSA docs say the problem doesn't exist because the 'dmix' plugin is
automatically engaged, but it's simply not factual, the automatic
solution just does not happen in a great many cases, and my new
very-low-noise pro audio sound card is one of them. I solved this one
by permitting only Jackd to output directly to the ALSA device;
everything else outputs either to ALSA's Pulse driver (thus far working
very well indeed) or to Pulse (itself designed to handle multiple
streams), which then hands the data to Jackd, which is tremendously good
at handling multiple streams, at the very low latencies which we need.
> Jonathan E. Brickman wrote:
Linux-audio-user mailing list