Difference between revisions of "Professional audio"

From ArchWiki
Jump to navigation Jump to search
m (System Configuration: pam realtime)
m (System Configuration: pam)
Line 114: Line 114:
  ~$ ps aux # or pacman -S htop && htop
  ~$ ps aux # or pacman -S htop && htop
* Is PAM-security and realtime working OK? Pay special attention especially if you do not run KDM, GDM or Slim.
* Is PAM-security and realtime working OK?
See: [[Realtime_for_Users|Realtime for Users]]
See: [[Realtime_for_Users#PAM-enabled_Login|Realtime for Users]] (Pay special attention especially if you do not run KDM, GDM or Slim.)
=== JACK ===
=== JACK ===

Revision as of 17:52, 14 October 2009


Modern Linux systems are more than capable of supporting your (semi-)professional audio needs. Latencies of 5ms down to even as low as 1ms can be achieved with good hardware and proper configuration. You could even run an industrial laser alongside your DAW.

We believe Arch Linux provides competent users the right "framework" to sculpt their very own dedicated machines for recording, mixing, mastering, sound-design, DSP programming, and what have you. More often than not, when a "linux audio user" thinks of "sculpting", he thinks of "Gentoo". It is unknown what has led to such fallacious thinking, but needless to say, "compiling", "learning" and "performance" have as much to do with each other as "differences in rendering quality between Cubase and Pro Tools".

Pro Audio on Arch Linux

  • Binary-based

Arch is primarily a (meta-)distribution comprising binary packages, with a system for easy source-based package management as well. No need to waste time compiling, you just work(tm).

  • KISS

The philosophy of Arch requires packages to remain as vanilla as possible. You get what upstream software developers want you to get, including no-nonsense and straightforward package names with all headers. No more headaches due to missing development files when building a new Linux audio application.

  • Rolling-release

Arch is fast-paced in releasing updates and deprecating the old, following upstream schedules. Linux Audio is, to a certain extent, an experimental paradigm. Arch allows you to be up-to-date in order to keep up with your favourite audio software.

  • ABS

Arch provides a simple BSD Ports-like source packaging system, allowing the user to easily compile software via a buildscript ("recipe") and pass the resulting binary to the package manager. This way, any and all kinds of software, regardless of where they are from, can be monitored by the system. The number of new Linux audio software is always growing, so this is definitely a plus if the only way to get them is to build them from source.

  • AUR

Arch has an "unupported" repository (AUR) of buildscripts open to all registered users for contribution, with thousands of ready-to-compile packages. Made for and by Arch Linux users. If something was released yesterday that would significantly help a number of users like you, chances are that today it has already been uploaded to the AUR.

  • Third-party Repositories

Arch in no way interrupts users when it comes to unofficial repositories that offer ready-to-run binary packages. It is simply a matter of adding one to the current list, and this is just in one file. No confusing "Whory Warthong", "Denim Jacket", "sources.list", or "source.keys" to worry about when you come across a new audio repository.

  • BSD-style init

Arch boots with a simple init mechanism, akin to most of the BSD systems. There is only one central configuration file, and as such, administration is quick. When running a DAW, the last thing a power-user wants is a complex underlying administration framework.

So should I use Arch Linux (as my DAW)? I have been using Distro X so far..

If such is your question, we are sorry to inform you that the answer is negative.

"Arch Linux does not find Archers, Archers find Arch Linux." - Hercules on Arch and Archers

Getting Started

Some of the major pro audio applications are already available from the official Arch Linux repositories. For anything which is not, you can either add a binary repository (see further down below) or if you prefer to compile, search the AUR. Nothing stops you from building directly off of upstream releases, but then you might as well run LFS.

For a quick start (assuming you have all official repositories enabled):

~# pacman -S qjackctl ardour ladspa-plugins dssi hydrogen lmms rosegarden

Other packages you may need and are available elsewhere:

  • JACK2
  • Qtractor
  • Traverso
  • LinuxSampler; JSampler; Qsampler
  • LV2
  • WineASIO

System Configuration

  • Have I set up sound properly? See ALSA.
~$ speaker-test
  • Am I in the audio group? See ALSA.
~$ groups | grep audio
  • Have I edited system limits?
# /etc/security/limits.conf
@audio - rtprio 99 # sane number is 65; up to 99
@audio - memlock unlimited # physical RAM divided by 2; up to "unlimited" (careful)
  • Is PulseAudio or something else grabbing my device? (Phonon does not)
~$ lsof /dev/snd/* # kmix, knotify, and any other friendly process are fine
~$ ps aux # or pacman -S htop && htop
  • Is PAM-security and realtime working OK?

See: Realtime for Users (Pay special attention especially if you do not run KDM, GDM or Slim.)


The aim here is to find the best possible combination of buffer size and periods, given the hardware you have. For onboard and USB devices, a period of 3 is always a must. Also, the sample rate must match the hardware sample rate. Most often, 48000Hz is the common default across many of today's devices. A buffer of 256 is a sane starter. Almost always, when recording or sequencing with external gear is concerned, realtime is a must. Also, you may like to set maximum priority (depending on allowance by system limits).

~$ /usr/bin/jackd -R -P89 -dalsa -dhw:0 -r48000 -p256 -n3

QJackCtl and Patchage are two GUI front-ends, of which the latter is only available in AUR/third-party repositories.

Further reading: http://w3.linux-magazine.com/issue/67/JACK_Audio_Server.pdf


You need JACK compiled with FFADO or FreeBob. Recompile (after installing FFADO somehow), find a binary or search the AUR, since the package from [extra] is purely vanilla (neither FFADO nor FreeBob has ever made it to the supported repositories).

To test whether you have any chances of getting FireWire devices to work:

~# modprobe raw1394
  • Am I in the video group?
~$ groups | grep video

Or whichever group has access to /dev/raw1394:

~$ ls -l /dev/raw1394 | awk '{print $4}'
  • Is my chipset sane enough to initiate a device?


  • Is my chipset sane enough to make a device work to its capacity?

We cannot say for sure, particularly for those based on Ricoh (cross-platform issue). Most of the time, your device will run fine, but on occasion you will be faced with funny quirks. For unlucky ones, you will be facing hell.

Realtime Kernel

Since a while ago, the stock Linux kernel has proven to be fine for realtime uses. So please, do not think that you need one just because you are running a studio.

Fallacy: I want to run a low-latency system, on which I will be recording an ensemble of 100 musicians through an array of RMEs. As such, I need a kernel patched for realtime.

The realtime patch was primarily designed for embedded systems and industrial applications, where the "realtime" is hard, really hard, realtime. Low-latency audio and/or multimedia is just an indirect result because for a long while, we had no other alternative.

Over time, the Linux kernel has accepted a good deal of improvements from the realtime tree, but most importantly it has improved itself significantly. With that said, however, there are ready-to-run/compile patched kernels available.

In any way, you should ensure that:

  • Dynamic Ticks (CONFIG_NO_HZ) is DISABLED
  • Timer Frequency is set to 1000Hz (CONFIG_HZ_1000)

If you are going to compile your own kernel, remember that removing modules/options does not equate to a "leaner and meaner" kernel. It is true that the size of the kernel image is reduced, but in today's systems it is not as much of an issue as it was back in 1995.

If you truly want a slim system, we suggest you go your own way and deploy one with static /devs. You should, however, set your CPU architecture. Selecting "Core 2 Duo" for appropriate hardware will allow for a good deal of optimisation, but not so much as you go down the scale.

You may also like to:

~# pacman -S irqbalance

See: http://irqbalance.org/

General issue(s) with (realtime) kernels:

  • Hyperthreading (if you suspect, disable in BIOS)


You can run abs (install it first), and recompile kernel26 with the patch. However, this is not the most useful of methods since updates will overwrite your custom kernel. You should at least change "pkgname".


From the AUR itself, you have two options:

  • kernel26rt
  • kernel26-ice

The former is a standard realtime kernel, while the latter includes patches some may consider to be nasty, while to others are a blessing.

Environment Variables

If you install things to non-standard directories, it is often necessary to set PATHs so that applications know where to look for plug-ins and other libraries. This usually affects LADSPA, DSSI, LV2 and VST. You may set them via a startup shell profile, eg. your user Bash user profile.

# ~/.bashrc
export LADSPA_PATH=$LADSPA_PATH:~/.ladspa:/someother/custom/dir
export LV2_PATH=$LV2_PATH:~/.lv2:/someother/custom/dir
export DSSI_PATH=$DSSI_PATH:~/.dssi:/someother/custom/dir
export VST_PATH=$VST_PATH:~/.vst:/someother/custom/dir

Tricks and Tips

  • Some daemons/processes can unexpectedly cause xruns. If you do not need it - kill it. No questions asked.
~$ ls /var/run/daemons
~$ top # or htop, ps aux, whatever you are comfortable with
~$ killall -9 $processname
~# /etc/rc.d/$daemonname stop

  • IRQ issues can occur and cause problems. An example is video hardware reserving the bus, causing needless interrupts in the system I/O path.

A helpful script: http://alsa.opensrc.org/Rtirq


M-Audio Delta 1010

This hardware requires that you install the alsa-tools package from the AUR, because it contains the envy24control program. Envy24control is a hardware level mixer/controller. You can use alsa-mixer but you will save yourself some hassle not to try it. Note that this section has no information on MIDI setup or usage.

Open the mixer application:

  • $envy24control

This application can be more then a bit confusing, and I am yet to find a reasonable tutorial for its use. That said, here is a working setup for multitracking with Ardour.

  1. Set all monitor inputs and monitor PCM's to around 20.
  2. Patchbay/router tab: Set all to PCM out.
  3. Hardware Settings: Verify that the Master Clock setting matches what is set in

Qjackctl. If these do not match you will have xruns out of control!

PreSonus Firepod

This hardware requires that you install the libffado beta or svn package from the AUR. You will also need these packages for FW control:

  • libraw1394
  • libiec61883
  • libavc1394
  1. Startup: Either from commandline or QjackCtl, the driver is called firewire.
  2. Specs: The card contains 8/8 preamp'ed XLR plus a stereo pair, in total 10


  1. Linking: Cards can be linked together without any problems.
  2. Hardware Settings: Nothing particular, tweak the settings in QjackCtl to your


Volume levels are hardware and routing can be done through QjackCtl, even with more cards linked together, this is not a problem. The ffadomixer does not work with this card yet, hopefully in the future we can control more aspects of the card through a software interface like that.

Presonus Firebox

This hardware requires the installation of libfreebob and jack-audio-connection-kit from svn, AUR, or using ABS.

You will also need these packages for FW control:

  • libraw1394
  • libiec61883
  • libavc1394

Be sure to load the kernel modules for firewire control:

  • modprobe ieee1394
  • modprobe raw1394

Then add them to the modules section of rc.conf

I had to change some udev specific configs found here.


If jackd complains: "Could not get 1394 handle: Permission denied:"

  • chmod a+rw /dev/raw1394

Add this line to rc.local so it runs on each boot

Arch Linux Pro Audio Project

Yes, we have one. Think "Planet CCRMA" or "Pro Audio Overlay", less the professional/academic connotations of the former: ArchAudio

What this means is that the repositories are add-ons, i.e you need to have a running, sane Arch Linux installation.

It is a relatively new effort although the initiative has been around since 2006/2007, so it may be missing a lot of packages. Most of the important ones, though, have been rolled out.

History: http://bbs.archlinux.org/viewtopic.php?id=30547

Currently, they have the following kernels:

  • kernel26rt

The "standard" realtime kernel.

  • kernel26daw

BFS-patched kernel for low-latency work.

All kernels (will) have their respective PAE, testing and x86_64 versions.

They also have variations of the jack-audio-connection-kit packages:

  • jack

The standard JACK, plus features and support not provided by the one in [extra].

  • jack2

The next-generation JACK.

SVN (development) versions of most packages are available too.

IRC: #archaudio @ Freenode