Linux system requirements

Hey, what about OS X ?

That gets a page of its own.

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. You can make your life 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 PlanetCCMRA, Agnula's Demudi or dyne:bolic)

You might also check PlanetCCMRA's guide to tuning as another excellent overview of what is involved.

Hardware

CPU and motherboards

You won't be able to do anything particular interesting with anything less powerful than a 200 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 email discussion is very helpful at explaining some of the deep technical issues involved.

Memory

Ardour will run on more or less any Linux system with at least 64MB 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.

Disk storage

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 interface

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.

Audio interface

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.

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

Software

The software requirements for running a powerful, capable and reliable digital audio workstation are no less important than the hardware, perhaps even more so.

Kernel

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.

If you need to run a 2.4 series kernel, you will need at least 1 kernel patch, the "low latency" patch from Andrew Morton, to make the kernel usable. Please be sure to read Andrew's notes on its use. In particular, note that low latency behaviour must be turned on: simply patching the kernel is not enough.

It is not possible for regular users on a normal Linux system to get solid realtime performance, and so to avoid having to run all your audio software as root (a very bad idea), there is a second kernel patch that is very desirable. This is the "capabilities" patch. Its very small, but it allows ordinary users to gain access to the powerful real-time scheduling policies and memory locking of the Linux kernel.

System

JACK

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

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 apt, emerge or 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 ardour
If you use emerge, then either of 
          emerge ardour
	  emerge media-sound/ardour
will install ardour for you.

If you insist on doing it yourself, you will need to ensure that your system has the following libraries installed:

  • JACK 0.98 or later
  • GTK+ 1.2 series
  • sndfile 1.0 or later
  • raptor
  • lrdf
  • XML2
  • samplerate
  • art_lgpl 2.3.16 or later