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