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