Malcolm Baldridge wrote:
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.
Thanks for the reply and your suggestions.
It looks like bdflush is no longer part of the 2.6 kernel; vm buffer
flushing is now handled by pdflush. The fact that this part of the
system is completely different in the 2.6 kernel may be a clue,
particularly in light of what you say a couple of paragraphs down. I'll
look into this a bit, I think.
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.
After reading your suggestion, I tried setting journal_data_writeback
using tune2fs, still had the same problem. I might just try reiserfs,
since I've read some people have had good luck with it for audio recording.
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.
I guess my main motivation for trying out the 2.6 kernel is laziness.
Just build the kernel and get the performance and ALSA without patches
or compiling extra stuff. At least, that was _supposed_ to be the way
it worked! I'll keep trying the new kernels, but keep the old faithful
2.4 kernel around for recording.
I'm _still_ curious about what causes the long xruns, though.
Thanks again,
Joel
The Dark Lord avoids new "release" kernels,
as they foul up his servers in
Barad-dur,
=MB=