Recorder7 Tweaks
File Systems
I have tested ext2, ext3, ext4, and XFS filesystems. And XFS is the best for performance. Make an XFS partition to record into and keep your operating system on one of the others. File journaling in the ext3 and ext4 file systems can slow things down. If used for a recording partition, ext3 and ext4 can be mounted with the option of relatime by adding the option in the /etc/fstab file.
Desktop Environments
The desktop environment doesn't seem to be a major factor with Recorder7. For example, Mepis' KDE works great. But, it makes sense to go as lightweight as you are comfortable with. XFCE is known to be a good blend of features versus weight. LXDE, Icewm, and JWM are even lighter on resources. For the fastest clock and meter displays try running Recorder7 from the xterm or rxvt command terminals.
Further System Optimization
What seems to happen on many distros is that when the system writes a large chunk of audio to disk, an xrun (audio glitch) can occur. Recorder7 is not really causing the problem. Recorder7 passes the audio file data to the system many times per second, but the system does not know that the data should be written to disk relatively quickly so it continues to hold onto the data (in RAM). Then the operating system steals processing power from Recorder7 and ALSA while it writes to disk. The distros that work well either write to disk more frequently or perform the disk write more efficiently. The easiest thing is to increase the Recorder7's audio buffer in the preferences (param.txt) file. Try a buffer of 1024, 2048, or 4096.
Also, you can put a limit on how long a disk write gets postponed. Most distros seem to have a default limit of 30 seconds for how long data can sit in RAM before it gets written to disk. This can be a relatively large amount of data to write within the size of an audio buffer. For example, 8 tracks of 24-bit audio at a 48 kHz sample rate is about 35 MB of data. So, on some systems you will get an audio glitch just after 30 seconds of recording. The tweak I have found to be helpful is to make a change to one file called dirty_expire_centisecs. This file is found in the directory /proc/sys/vm and is edited with a text editor. The number you will typically see in this file is 3000 (centiseconds) which is 30 seconds. You can try setting it between 300 to 1000. At a setting of 300, a disk write should occur about every 3 seconds and therefore reduce the amount of data that needs to be written and probably the time needed to write it by a factor of 10. Note that making this number too low would make the hard disk write more often than it should, so be careful.