[linux-audio-user] Ardour, Jack, and 2.6 kernels

[Malcolm Baldridge]

> I get the impression that there is a sporatic event that is causing the 
> unusually long xrun.  If anyone has any ideas, I would greatly 
> appreciate advice on how to track this down (reiserfs, maybe?).

I suspect as you've recorded a fair bit of material and have put pressure on
the disk cache buffers (as lots of writes will do), you are probably being
bitten by some not-so-nice buffer dumping.  I've written (at length) about
tuning the buffer flushing Virtual Memory Manager code via /proc file system
controls.  Google/search for bdflush.

Also: ext3 in its default mode has very burpy latency on heavy writes.  You
can adjust it via a different journalling mode (specifiable in /etc/fstab,
with data=writeback in the options section for the volume in question), or
use reiserfs (or a non-journalling filesystem altogether, like ext2).  You
can try the different journalling mode first.

Don't be fooled by the even-numbered version of the kernel.  There's nothing
"stable" about 2.6.x really.  From rev-to-rev it's changing a great deal
within the infrastructure.  If 2.4.x is working for you, STICK WITH IT.

In fact, this should be Rule #1 for Linux-Audio (and any other
purpose-specific application task).  Stick with the tried-and-true which
gets your work accomplished.  Chasing bleeding edge kernels and whatnot is
only going to get you bitten.  Remember who the one doing the BLEEDING is.

Oldtimer Linux kernel-heads will tell you the same thing.  A new kernel
isn't really "stable" until the teens or so at least.  2.4 had WICKED,
FATAL, and DATA-CORRUPTING bugs until 2.4.17, and had OOPS/lock-up bugs in
mainstream network controller drivers until 2.4.15 or 2.4.16.  Don't ask how
I found those, or how far away from the machines I was when these occurred.

The Dark Lord avoids new "release" kernels, as they foul up his servers in
Barad-dur,

=MB=
-- 
A focus on Quality.