So, based on Fernando's and Malcolm's advice, I decided to quit fussing with the 2.6 kernels and stick with the 2.4.23 that I have working to do some recording last night. The band came over - we were set and ready to go. I hit 'record' to get an idea of the drum mix (we're submixing to stereo) - 3 seconds in, Ardour stops with an 80ms xrun! Arrgh! I sweated through the rest of the evening, fearing another occurence at 3:30 into a 4:00 song. Fortunately, everything went ok. I guess I'm back to trying to figure out what's causing these long xruns, now under the 2.4.23 kernel. Do most people shut off non-essential daemons during recording sessions, or do any other tricks? This is kinda frustrating, as the CPU load seems rather low (< 15% when the xrun happened). I guess I'll test out reiserfs and even ext2 to see if the filesystem is the culprit. Thanks for reading the ramble, Joel > > 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. > > New versions of alsa can be compiled with the "--debug=full" option (I > don't think the current code in the kernel has that). That will enable > you to tweak a proc variable to dump the kernel stack on each xrun, it > is something like /proc/asound/card0/pcm0p/xrun_debug (for playback, > same for recording in pcm0c). "echo "2">/proc/.../xrun_debug" will turn > reporting on. You will get the stack traces in /var/log/messages. > > Not that you will immediately know exactly what has to be done to get it > fixed, of course :-) > > IMHO stick with 2.4.x, in my tests 2.6.x is not even close to being > ready for pro audio work. It will get better but it will take some time. > > -- Fernando > >
