I'm using ardour to do around 8 tracks of audio, not all have regions active all the time. Playing a session through the first time, I get grrrtz every so often, usually but not always accompanied by an xrun report from jack. It's correlated with disk activity. Which is a Fujitsu MAN3367 on an Adaptec 29160 and according to hdparm can do around 50Mb/s. Although in ardour the disk throughput indicator shows anything from 9 to 14, depending on the number of regions being played, and the scheduler settings in use. I guess that's because the disk has to seek for the data for various different regions. Which are on a Reiserfs partition. I'm using an Athlon 2200+ on an MSI motherboard with 1Gb of memory. This is after my nice dual-athlon motherboard died, which had none of these problems. <sigh> I'm using 2.6.0-test11 kernel (with pre-emption), and I've tried the as scheduler (with various settings), the cfq scheduler and the deadline scheduler (which seemed to be the worst for this kind of low-latency work). It's subjectively better than 2.4.22 with low-latency and pre-emption patches. top shows that whenever there's a dropout, the CPU has just spent anything from 6 to 30% on io wait. It's definitely not a sound card issue - once the session has played through once and the audio files are cached, I get flawless playback with ardour showing disk throughput of 190Mb/s, even with a compile going in the background. I spent a few days playing with PCI latencies as well, but that didn't make a difference. Dropping the SCSI controller tagged queue depth to 4 makes recording more reliable, but doesn't really help otherwise. It also doesn't seem to make much of a difference if I run jack with buffer size of 1024 or 256. I haven't tried lower than that, and the card (Terratec EWS88MT) won't go higher that -n 2 -p 2048. Short of getting another dualie motherboard (which is a PITA in this country, and expensive), is there anything else I can try? low-latency patches for 2.6 kernels? thanks John