Save yourself time, energy and trouble
Setting up a computer as a digital audio workstation is a nontrivial task whether it runs Windows, MacOS or Linux. Linux users can make their lives much easier by:
- Following the hardware recommendations below
- Using a Linux distribution or distribution add-on that is tailored for low-latency multimedia work (such as Ubuntu Studio or PlanetCCMRA)
You might also check PlanetCCMRA's guide to tuning as another excellent overview of what is involved.
CPU and motherboards
You won't be able to do anything particular interesting with anything less powerful than a 400mhz Pentium equivalent CPU, and for working on heavily multitrack, plugin-laden sessions, a contemporary 1-3GHz system will make your life much easier. Because of their superior floating point performance, Athlons are preferable to Intel CPUs. For maximum performance, a dual CPU system is a great choice: not only will the audio/DSP part of your system run completely reliably, but the GUI of Ardour and other tools will stay smooth and responsive.
Avoid VIA motherboards and chipsets wherever possible. This company has demonstrated an almost complete disregard for reasonable use of the PCI bus. Their hardware has repeatedly been implicated in a failure to achieve low latency performance. Here is one example of the kinds of problems you can expect.
Check your system for interrupt sharing. See
/proc/interrupts for the assignments in use. On some
systems, particularly laptops, you will see spectactularly bad
interrupt sharing and it can be very hard to fix this. Older Linux
kernels used to provide a way to define interrupt usage; current
versions appear to rely on the BIOS to get it right. Many current systems,
again laptops in particular, have a BIOS that offers no
control over this. This
discussion is very helpful at explaining some of the deep
technical issues involved.
Ardour will run on more or less any Linux system with at least 256MB of RAM. The more memory you have, the better Ardour will handle large sessions. 512MB is a more reasonable memory configuration, 1GB is very nice. Please note that if you are compiling Ardour yourself, the link step (particular of a debug-enabled version) is extremely memory intensive - 512MB is not enough to link without swapping. This issue does not affect the use of Ardour.
You should also have a disk subsystem featuring at least 7200RPM disk drives (10K or 15K RPM will be even better). Using a second (non-system) disk drive for audio is recommended, although not essential.
SCSI drives are recommended. Firewire drives (even Firewire chassis with an internal IDE interface) are likely to also work very well indeed, sometimes better than SCSI. If you want to benefit from the low cost of IDE drives, housing them in a Firewire chassis is by far the best way to do it.
If using (E)IDE/ATA disk drives, ensure that DMA mode is enabled
(see the manual page for
hdparm). Many modern
Linux distributions enable this by default. In addition, do
not allow IDE disk drives to share IDE controller channels: do
not chain them together and do not allow other IDE devices
such as CD-ROM drives to coexist on the same channel either.
Video interfaces are often a chronic weakspot for a digital audio workstation. Sometimes this is caused by poor hardware design, sometimes by poor device driver design (sometimes caused by lack of information from the manufacturer), and sometimes by both of these factors. The central problem tends to be over-aggressive hogging of the PCI bus - the video interface and/or its device driver believes that it is the most important hardware on the bus, and prevents other hardware (e.g. your audio interface) from using it for excessive periods of time.
One excellent choice is to use an old Matrox video interface. They are not fast for gamers, but audio is not a game. Old Matrox adapters such as the G400 and G450 make excellent devices for audio workstations (the G450 is dual head with optional TV-output). Unfortunately, it seems unlikely that Matrox will make open source drivers for their newer cards available soon.
Other video interfaces will work, but with varying success. VIA chipsets (as noted above) are a poor choice. In addition, some video interfaces require binary device drivers that may not work with the customized kernel you need for audio work to be reliable and low-latency.
You may need to tweak the PCI bus latency settings for your video adapter (and possibly other PCI hardware). This is quite a complex procedure at present (this GUI tool might help). You can read this guide to get you started.
For high-end use, the RME Hammerfall series and the M-Audio Delta series are both recommended choices. These devices are well-supported under Linux, have excellent hardware designs, and work well in more or less every respect.
For cheaper hardware, any of the cards based on the ICE1712 or ICE1724 chipsets will work well (Terratec and M-Audio use these, as well as the EZ8), and the Ensoniq cards and onboard chipsets also are well supported and fairly reliable. On laptops, you may run into cheap builtin audio interfaces that have a single fixed sample rate. This is a poor situation to be in for pro-audio work: resampling is rarely computationally cheap, and always causes compromises with quality.
See the page on audio hardware support for more information on support of particular devices.
Things Not To Do
- Do not plan to gang together cheap stereo soundcards to make a multichannel system: this will not work.
- Do not plan to use USB audio interfaces if low latency is important to you
The software requirements for running a powerful, capable and reliable digital audio workstation are no less important than the hardware, perhaps even more so.
Once again, you can save yourself a lot of trouble with kernel configuration by using a Linux distribution such as Planet CCRMA, Agnula or dyne:bolic that comes with a properly configured kernel. If you insist on doing it all yourself, then read on.
It is recommended that you run a 2.6 series kernel, preferably 2.6.14 or later. This kernel has the best out-of-the-box performance of any that we have seen to date, and includes the basic support for all users to have access to real time scheduling, a requirement for good audio performance. You will probably still need to update your user-space tools (PAM in particular, or its equivalent) to get RT scheduling configured properly.
For even better, almost insanely great performance, you can run a 2.6 series kernel patched with Ingo Molnar's RT patch, which provides almost hard realtime like performance. It is possible to get down to 16 frames of input latency with such a kernel. For context - many audio interfaces do not allow settings below 64 frames.
It is not possible for regular users on a most current Linux systems to get solid realtime performance, and so to avoid having to run all your audio software as root (a very bad idea), your system should also have a reasonably current version of PAM. Versions 0.79 and above allow the use of a configuration file (
/etc/limits/security.conf) to grant realtime scheduling and memory locking rights to ordinary users. Some audio/media-focused distributions set up this file by default; on most other Linux systems you will have to edit the file by hand (and we need a link here to show you what to do, but for now google for: pam limits.conf rtprio).
Although JACK itself is just a server and can be run from a text console, you will your life much happier by using Rui Nuno Capela's excellent GUI for JACK: qjackctl.
For recording and other critical situations, please ensure that JACK is started in real-time mode. Use the setup dialog in qjackctl, or the -R flag for cmdline use. You will need a kernel with the capabilities patch for this to work if you do not want to run all your audio applications as root.
If you are building JACK from the source release, there are many issues to consider. You are much better off using a package for your Linux distribution.
Ardour requires quite a large number of software libraries that you
probably do not have installed already. Your life will be much easier
if you use a package management system like
yum to take care of the dependencies for you. If you use
apt, then the following command will install ardour for you:
apt-get install ardourIf you use emerge, then either of
emerge ardour emerge media-sound/ardourwill install ardour for you.
If you insist on doing it yourself, you should go and read the build instructions.