> 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.
