18 Dec
2003
18 Dec
'03
6:37 a.m.
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