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