Linux is a pretty efficient operating system, so you don’t need to, go to heroic lengths to make it get out of its own way. However, there are a few things you can do to ensure the best possible performance.
High-powered PC hardware is always good and is cheaper than high-end audio devices. My audio workstation has an AMD Phenom X3 2.4 GHz CPU, 4GB of RAM, and a terabyte’s worth of SATA II hard drives. Those extra cores make a nice difference, because even though Audacity is not optimized for multicore processors, those extra cores mean faster, smoother multitasking. I also have an old laptop with a 1.4 GHz CPU, 1GB of RAM, and a slower hard drive. This handles up to four-channel 16/44.1 recording capably, but at higher bit depths or sampling rates it tends to stall. I consider a 1 GHz CPU and 512MB of RAM to be the bare minimum for music recording and editing. For podcasts and spoken-word recordings, you can go as low as 128MB RAM and a 500 MHz CPU.
Turn off your screensaver and all fancy video effects. All that CompizFusion bling is pretty, but it gets in the way of good audio. In fact, you should turn off everything that is not absolutely needed: Don’t run other applications, and turn off unnecessary services. There usually isn’t too much cruft; Bluetooth, wireless daemons on systems without wireless devices, and Wacom tablet daemons are the most common on-by-default services that most users don’t need.
Both KDE and GNOME are heavy-duty desktops that feast on CPU and memory, so you can slim your system down by using a lighter-weight graphical environment such as Xfce, IceWM, LXDE, Fluxbox, or any of the many other lightweight Linux graphical environments.
Video is the single most demanding system on your PC, so you might want to upgrade to a better video card. Many lower-end systems use shared system memory instead of a dedicated graphics processing unit (GPU). In other words, they use some of your system RAM to process video, and this is quite a bit slower because it places an extra load on your system RAM and CPU, both of which are considerably slower than a GPU. GPUs are so much faster that they are used to build clusters for very fast, very powerful, high-end scientific calculations.
Depending on your distribution, you should have a good graphical
system resources monitor so you can see where your system resources are
being used. The good old-fashioned top command is still a useful tool for viewing
active processes and how much system resources they are using. After
starting top, press 1 to see all the
cores in a multicore CPU:
$ top Tasks: 232 total, 1 running, 231 sleeping, 0 stopped, 0 zombie Cpu0 : 3.7%us, 0.7%sy, 0.0%ni, 95.7%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu1 : 7.6%us, 0.7%sy, 0.0%ni, 90.1%id, 1.7%wa, 0.0%hi, 0.0%si, 0.0%st Cpu2 : 0.0%us, 0.7%sy, 0.0%ni, 99.3%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 4056672k total, 1602700k used, 2453972k free, 171880k buffers Swap: 7092636k total, 0k used, 7092636k free, 655412k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 17132 alrac 20 0 663m 35m 22m S 8 0.9 0:27.99 audacity 2208 root 20 0 181m 83m 14m S 3 2.1 32:02.89 Xorg 10683 alrac 20 0 620m 147m 28m S 1 3.7 4:37.10 firefox 2763 alrac 20 0 212m 10m 8276 S 1 0.3 3:00.33 multiload-apple
This shows that all is well. The summary at the top tells us many things: One process is running, and the rest, all 231 of ’em, are sleeping. Three CPU cores are chugging away.
All of these fields are explained in the nice man page, man top. Your version of top may display different fields, but it is
still the same top command. The top
section is the summary, and the bottom section is the task area.
CPU states (in the summary) are fun to examine in detail, but the
main fields to keep an eye on are the us, or user field, which shows the load per
CPU, and the sy, or system field,
which shows the load from kernel processes. If you are seeing sy values greater than 10 percent
consistently, you should track down the cause, because ordinarily it
should be in the single digits.
The Mem and Swap fields tell you whether your physical RAM
is sufficient. As long as Swap usage
is zero and your Mem is not maxed
out, that is ideal for audio processing, since RAM is many times faster
than a swap file, which is on your hard disk.
Down in the task area, you see information on every process on your system. Again, don’t go crazy on the minute details, but look at the biggest users at the top. This quickly reveals who the CPU and memory hogs are. Web browsers can be awful hogs in this era of lardy, script- and Flash-heavy websites, so shut ’em down. Audio processing chews up a lot of CPU cycles, so that’s the main thing to keep an eye on. If you’re hitting greater than 75 percent consistently, think about upgrading your CPU. The Linux kernel and most CPUs don’t mind working that hard, but at that level you’re probably noticing slower performance.
You can tune your swap file size a bit for better performance. If you have 512MB of RAM or less, make your swap file size at least equal to your RAM size. If you have 1GB of RAM or more, make your swap file no larger than half your RAM. But don’t remove your swap file entirely—laptops need them for suspend and hibernate, and if you ever use up all of your physical memory, that swap file might save your recording session.
If you are using a PCI sound card, check your motherboard manual to find a slot that does not use shared interrupts. PCI-Express sound cards are great because PCI-E uses dedicated buses, rather than shared buses like the old PCI 2.0 standard. There are not a lot of PCI-E sound cards yet; the RME HDSPe MADI series, for one example, is first-rate and works in Linux.
Don’t use networked file shares, except for storing backups of your audio files, because they’re too slow.