[linux-audio-user] xrun madness - test results (long)

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: [linux-audio-user] xrun madness - test results (long)
From: Joel White (cv223_AT_comcast.net)
Date: Tue Oct 26 2004 - 06:26:33 EEST


A few days ago, I posted a message seeking help in debugging xruns using
jack and ardour on my system. Joel Roth suggested that I simplify my
problem by using ecasound, so I'd like to submit a "lab report" on what
I've found. I have a couple goals: to see if anyone may have
suggestions on what could be going on, and to "give something back" to
this great audio community by doing some testing (I hope it will be
useful to someone).

Acknowledgements: Thanks to everyone who sent suggestions, particularly
Lee with help on the kernels and to Joel, Eric, Rocco, and Kai with
ecasound tips.

Introduction: I set up an SMP system with a SCSI Raid0 drive for doing
audio recording (both SMP and Raid were suggested on various web sites
for an audio system). Using a Delta 1010LT, ardour, and jack for
multi-track recording, I could not eliminate xruns, first with 2.6
kernels, then back to 2.4.23 + low latency patch. I tried an IDE drive
and the xruns virtually disappeared. Partly due to stubborness and
partly due to curiousity, I have tried to track down what is going on.
A comment on the ST Audio web site suggested that the Adaptec controller
was the problem (by "holding onto the PCI bus"), but Justin Gibbs (who
worked on the aic7xxx driver) expressed doubts to the ST Audio
explanation. Patches to the recent 2.6 kernels include preemption but
also latency diagnostic capabilities, so I thought I would check whether
the kernel was the problem. This then led to further latency tests
using ecasound under both kernels and under various alsa and jack
conditions. The results suggest (to me, anyway) that the problem isn't
simply the hardware (if at all). I hope that someone may be able to
shed some light based upon the clues I've assembled.

Materials & Methods:

Hardware - ALR 7200 mobo with dual 600 MHz PIII, 512 MB ram, Adaptec
7890 SCSI controller, 4 Seagate drives configured in a Raid0, Maxtor IDE
drive, Delta 1010LT soundcard

Kernels - 2.4.23+low latency patch+capabilities, 2.6.9-rc2-mm4-VP-S7
with realtime-lsm

Software: ecasound-2.3.3, jack-0.98.1, ardour-0.9_beta1-r1, gentoo distro

Results:

Ecasound ALSA tests - To test the drives using a basic ALSA recording
setup, the following ecasound command was used to record 8 channels and
write the results to a single file. The output format was 32 bits to
match what Ardour is writing. The inputs were simply routed to the
outputs (I've also tested mixing the outputs to two channels). Buffer
size was set at a reasonably small value.

ecasound -r -b:128 -a:1,2 -f:32,8,48000 -i alsa,default \
-a:1 -f:32,8,48000 -o output1.wav \
-a:2 -f:32,8,48000 -o alsa,default

With either 2.4.23 or 2.6.9 kernels, this records without snaps,
crackles, pops, overruns, or underruns to both Raid0 and IDE drives! (I
also tested writing 8 mono output files with the same result). In fact,
I can double the output to disk like so:

ecasound -r -b:128 -a:1,2,3 -f:32,8,48000 -i alsa,default \
-a:1 -f:32,8,48000 -o output1.wav \
-a:2 -f:32,8,48000 -o output2.wav \
-a:3 -f:32,8,48000 -o alsa,default

and still have flawless recording (as long as I'm not doing any disk
writes on the system, that is). The Raid0 does not seem to be a problem.

Ecasound Jack tests - To test whether Jack is performing ok on my
system, the following ecasound command was also run, with jack running
at 48000Hz, with -n 2 -p 128 Duplex.

ecasound -a:1,2 -f:32,8,48000 -i jack_auto \
-a:1 -f:32,8,48000 -o output1.wav \
-a:2 -f:32,8,48000 -o jack_auto

This again recorded flawlessly, as did doubling the output to disk.

During early tests, I found that running envy24control while recording
literally *spewed* overruns, underruns, and xruns. So, I don't do that
anymore.

Ardour and Jack tests - A simple Ardour template was set up with 8
tracks, sending two channels of playback to the Delta (this is closer to
what I'm doing when recording my band, but without the additional
routing). Jack set at 48000 -n 2-p 256 Duplex.

With 2.4.23 - On the Raid0, xruns occur at a rate of about 25 per 30 sec
of recording. On the IDE, an xrun will occur only rarely (once in
several minutes). On the Raid0, a handful of xruns still occur per
minute with -p 2048 (the highest possible setting). Xruns do not occur
when Jack is running in Capture to either drive (then I would use the
1010's hardware monitoring).

With 2.6.9 - In Duplex mode, xruns occur at a rate of scores per min of
recording on *either* drive. Kernel latency trace indicates that the
max kernel latencies were around 200 - 400 usec. Xruns are eliminated
when Jack is set to Capture only.

Conclusions:

1. The ecasound tests indicate that the SCSI system is not the problem
per se. Flawless recordings at low latency are possible, even stressing
the disk system.

2. The ecasound tests also indicate that jack is not a problem.

3. It seems that there is some kind of interaction between Ardour, the
kernel, and the disk system. The fact that xrun behavior is so
different between the two kernels (xruns on the IDE drive with 2.6.9,
but not 2.4.23) suggests something is up with the kernel. The
latency_trace on 2.6.9 does not report that the kernel latency is the
problem, but it is clearly something going on with this kernel. It is
certainly possible that I have something misconfigured (Lee Revell
checked out my .config, so at least that seems ok). I can send more
info to anyone who may be able to help.

4. I will certainly stick with the 2.4.23 kernel for recording onto the
IDE drive, and for recording basic tracks I will use Capture mode and
hardware monitoring. There is still the spectre of occasional xruns
while recording overdubs and things (when I have to use Duplex), but
that is not as bad as having an xrun in the middle of recording basic
tracks with the entire band.

5. I would like to stick with Ardour for band recording, but ecasound is
cool, too, so I'll keep it in the toolbox as well.

6. I will not run envy24control while recording.

7. I will try out newer versions of the various programs next
(particularly ardour).

If anyone has any suggestions, please let me know! Thanks for reading.

Joel


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Tue Oct 26 2004 - 06:59:26 EEST