Why Linux Is Not Ready For Professional Recording Studios. A How-To.

https://wiki.archlinux.org/index.php/Pro_Audio

I can click twice and in 5 seconds have Reaper up and running.

Linux?

Read about the clusterfsck below.


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/CPU cycles, you just work(tm). This leads to "Third-party
Repositores" below.

* 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.

* Pragmatic

Arch is agnostic with regards to licenses of software - it includes
packages in the official repositories which "taint" the freedom of a
distribution, but otherwise are popular and/or useful. This is also
possible because Arch is not a complete "distribution", i.e releases are
in fact only snapshots of the system with base packages only. License
information is clearly available with every package without the need for
installation, so it is up to the user to decide what he installs.

* 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 "unsupported" 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. We can afford
to skip PEBKAC safeguards, because we expect users to know what they are
doing. This means deciding on whether using a particular binary
repository is "safe". For third-party Arch Linux binaries of audio
software, we have this.

* 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.

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

A: 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 and community 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:

~# pacman -S qjackctl patchage ardour qtractor hydrogen rosegarden
qsynth lmms ladspa-plugins dssi-vst

Other packages you may need and are available elsewhere:

* JACK2
* Traverso
* LinuxSampler; JSampler; Qsampler
* FST-GIT
* JOST
* 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, OSS or something else grabbing my device? (Phonon
does not but you may want to install phonon-xine)

~$ lsof +c 0 /dev/snd/pcm*
~$ lsof +c 0 /dev/dsp

* Is PAM-security and realtime working OK?

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

* Have I rebooted after having done all that?

JACK

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 (at least
10 lower than system limits; the highest is for the device itself).

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

QJackCtl and Patchage are two GUI front-ends.

And to check what sample and bit rates your device supports (for what
samplerate it is set to, you have to look up the device manual or the
knobs/switches/buttons on it):

~$ cat /proc/asound/card0/codec#0

Replace card0 and codec#0 depending on what you have. You will be
looking for rates or VRA in Extended ID.

Further reading:
http://w3.linux-magazine.com/issue/...Server.pdf
FireWire

JACK is now built against FFADO (currently in [testing]):

~# pacman -S jack libffado

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

* Ensure the proper kernel modules are loaded:

~# modprobe firewire-core firewire-ohci

* For the old stack (eg. custom kernels; Arch has only the new
stack):

~# modprobe ieee1394 raw1394

* Am I in the video group?

~$ groups | grep video

Or whichever group has access to /dev/fw1 (/dev/raw1394 in old stack):

~$ ls -l /dev/fw1 | awk '{print $4}'

You can also ammend the permissions for your needs (for new stack see
upstream documentation):

~# chmod 666 /dev/fw1

* Is my chipset sane enough to initiate a device?

http://www.ffado.org/?q=node/622

* 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.


Jack Flash

If after getting jack setup you will find that Flash has no audio.

In order to get flash to work with jack you will need to install
libflashsupport-jack from the aur repositorys.

http://aur.archlinux.org/packages.php?ID&219
Quickscan Jack script

Most people will probably want to run jack in realtime mode, there are
however a lot of nobs and buttons to press in order for that to happen.

A great way to quickly diagnose your system and find out what it is
missing in order to have jack work properly in real time mode is to run
the Quickscan script.

http://realtimeconfigquickscan.goog...ickScan.pl

The output should tell you where your system is lacking and will point
you to places to find more information.
Realtime Kernel

Since a while ago, the stock Linux kernel has proven to be adequate for
realtime uses. The stock kernel (with CONFIG_PREEMPT=y, default in Arch)
can operate with a worst case latency of upto 10ms (time between the
moment an interrupt occurs in hardware, and the moment the corresponding
interrupt-thread gets running), although some device drivers can
introduce latency much worse than that. So depending on your hardware
and driver (and requirement), you might want a kernel with hard realtime
capabilities.

The RT_PREEPMT patch by Ingo Molnar and Thomas Gleixner is an
interesting option for hard and firm realtime applications, reaching
from professional audio to industrial control. Most audio-specific
distro Linux ships with this patch applied. A realtime-preemptible
kernel will also make it possible to tweak priorities of IRQ handling
threads and help ensure smooth audio almost regardless of the load.

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.

In any way, you should also ensure that:

* Timer Frequency is set to 1000Hz (CONFIG_HZ_1000=y; if you do not
do MIDI you can ignore this)
* APM is DISABLED (CONFIG_APM=n; Troublesome with some hardware -
default in x86_64)

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.

General issue(s) with (realtime) kernels:

* Hyperthreading (if you suspect, disable in BIOS)

There are ready-to-run/compile patched kernels available in the ABS and
AUR.
ABS

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".
AUR

From the AUR itself, you have two options:

* kernel26rt
* kernel26-rt-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 environment path variables so that applications know where to
look (for plug-ins and other libraries). This usually affects only VST
since users might have a Wine or external Windows location.

We would usually not have Linux plug-ins (LADSPA, LV2, DSSI) beyond
standard paths, so it is not necessary to export them. But if you do, be
sure to include those standard paths as well since Arch does not do
anything for dssi or ladspa, and some applications like dssi-vst will
not look anywhere else if it finds predefined paths.

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

Tricks and Tips

* IRQ issues can occur and cause problems. An example is video
hardware reserving the bus, causing needless interrupts in the system
I/O path. See discussion at FFADO IRQ Priorities How-To. If you have a
RT_PREEMPT patched kernel, you can use this helpful script rtirq to
adjust priorities of IRQ handling threads.

* Do not use the irqbalance daemon, or do so carefully [1].

* 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

* If you are facing a lot of xruns especially with nvidia, disable
your GPU throttling. This can be done via the card's control applet and
for nvidia it is "prefer maximum performance" (thanks to a mail in LAU
by Frank Kober).

Hardware
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

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

channels.

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

likings.

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.
Restricted Software
Steinberg's SDKs

It is very clear - we can distribute neither the VST nor the ASIO
headers in binary package form. However, whenever you are building a
program which would host Windows .dll VST plug-ins, check for the
following hints (that do not require use of any SDK):

* dssi-vst
* fst
* vestige

With that said, if you are building a program which would host native
.so VST plug-ins, then there is no escape. For such cases, Arch yet
again allows us to maintain a uniform local software database. We can
"install" the SDK system-wide - you simply have to download it yourself
and place it in the packaging directory.

Get them from AUR

Note: Steinberg does not forbid redistribution of resulting products,
nor dictate what license they can be under. There are many GPL-licensed
VST plug-ins. As such, distributing binary packages of software built
with these restricted headers is not a problem, because the headers are
simply buildtime dependencies.
Arch Linux Pro Audio Project

Yes, we have one. Think of "Planet CCRMA" or "Pro Audio Overlay", less
the 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.

History: http://bbs.archlinux.org/viewtopic.php?id0547

Update: In end of 2010 / early 2011 we received an major increase in
human resources and motivation that resulted in more than 400 new
packages currently being tested. Please check our [testing] repository.

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 / GIT / HG (development) versions of most packages are available too
in our [experimental] repository.

IRC: #archaudio @ Freenode