[linux-audio-user] rezound as jack client

Malcolm Baldridge linux-audio at paypc.com
Fri Apr 30 19:42:51 EDT 2004

> I have tried ardour and qarecord for recording without xruns.
> I know there are some problems in ReZound from this point of
> view (and Davy knows about them much better :-). I have hoped,
> you know some magic steps to configure something somewhere
> to eliminate the issue at current ReZound state :-)
> Well, may be it is offtopic for this thread, but another question
> is here: which (and where is it) kernel patch is most appropriate for
> jack-functioning for 2.4.26 (I have applied lck1 patch)?

I will assume you're using a SCSI system, and/or have your IDE tuned to use
-d1 -u1 -c1 -m16 appropriately, and have 80-pin cables to do full UDMA/100
(or better) performance.  7,200+ RPM drives are also a Good Thing(tm).

One thing people forget in tuning their system, is configuring their VMM
system to not postpone dirty buffer flushes to disk.  Actually, if you CAN
try to avoid using swap at all, or use a dedicated swap device on its own
IDE channel (or use SCSI).  Do not underestimate the logjams of contended
I/O devices.

Also, you'll want to keep a reign on dirty buffer highwater marks.  System
defaults are not tuned for deterministic latency, i.e., writes are delayed
until there's a lot of them.  To produce more even and distributed writes,
you might want to try:

Assuming an HZ=1000 kernel...

echo "10 64 0 0 2000 15000 90 5 0" > /proc/sys/vm/bdflush

Assuming stock HZ=100 kernel:

echo "10 64 0 0 200 1500 90 5 0" > /proc/sys/vm/bdflush

This means: wakeup bdflush() at 10% dirty buffer levels, issue 64 block
writes maximum per pass, wake up every 2 seconds, don't let dirty buffers
age more than 15 seconds.  bdflush() can go into "panic mode" to use
synchronous operations when dirty buffers reach 90%, and bdflush can stop
waking up when dirty buffer levels get to 5%.

Defaults provide for a more deferred bdflush interval, and much larger I/O
requests [500 blocks], which can flood the device's request queue and block
other writes from occurring.

If you're using lck1, are you also performing a "echo 1 >
/proc/sys/kernel/lowlatency" ?

Try 'nice -10'ing your problematic process.

Also, avoid using ext3 in its default mode, ordered writeback. Instead,
mount it using writeback journalling mode. Large pending journal updates
tank latency as a sizeable operation needs to be performed atomically.  The
mount options for ext3 (if you must use it) would be: -o

/etc/fstab entry would be like:

/dev/hdc1       /barad-dur          ext3     noatime,journal=writeback

Note: this mode still journals all meta-data writes, but data CONTENT is now
write-ordered, so you might not have the data you expect in a kernel
OOPS/crash scenario, but your filesystem structures won't be damaged.

noatime turns off the potentially disruptive ACCESS time updates (needless
write pollution if you're reading many files during the course of your
sessions).  Modification time updates are still performed of course.

When the Lady Galadriel comes calling, be sure of your Quality,


A focus on Quality.

More information about the linux-audio-user mailing list