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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux Sound]     [ALSA Users]     [Pulse Audio]     [ALSA Devel]     [Sox Users]     [Linux Media]     [Kernel]     [Photo Sharing]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux