2 Nov
2009
2 Nov
'09
7:52 p.m.
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
one happen.
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.
J.E.B.
Jonathan E. Brickman wrote:
Guru, do you know what was/is the CPU load during
the episode?
J.E.B.
No, Jonathan, unfortunately I didn't check... was running behind
schedule before the gig, and haven't been near my system since. It may
take a while for me to get back to my system, and checking CPU load
will be the first thing I intend to do.
Couple of other things that I missed out in previous posts. Firstly,
before the gig I wanted to check whether it was a qsynth-specific or
general fluidsynth issue, so I installed ghostess, which can run
multiple instances simultaneously. I loaded the same soundfonts, and
experienced exactly the same issue - so if there's a bug in the app,
then it must be in the fluidsynth libraries.
Second issue of note: few weeks ago, while still running Ubuntu, I
wanted to find out what exactly caused the jack crash that I reported
on this list at the time (perhaps unrelated to the current issue) . I
found a "stress test" to replicate the problem: hitting a lot of notes
while keeping my sustain pedal down. Initially, the crash would happen
within 20-30 seconds of banging the controller (!). When I changed the
polyphony settings from 256 to 64, it would be much more stable - for
more than 10-15 mins of banging! Again, I was able to replicate the
same thing with ghostess.
This incident has left me with a lurking suspicion about a possible
bug in the fluidsynth libraries. I'm curious, though... has anyone
else experienced similar issues?
Looking forward to pointers/feedback/suggestions.
Cheers,
Guru