Realtime and SMP Kernels
Realtime Preemption
For serious audio recording and editing it's a good idea to compile the kernel
with Ingo Molnar's
realtime-preempt (-rt) patch
(unless you're using multiple sound cards).
Without this the kernel can produce latencies of up to 10ms even if
CONFIG_PREEMPT=y is set.
The -rt patch applies to the relevant standard kernel.org release.
For example, patch-2.6.14-rt20 applies to the 2.6.14 kernel.org
source, and will not necessarily work with 2.6.14.1 etc. It will definitely not
work with your distro's kernel source. (Some specialised distros like CCRMA use
the -rt patch already, however). Sometimes a version of the -rt patch will not
work with a particular configuration, but these problems usually get fixed
quickly. It's a good idea to check on LKML
for any issues regarding the current -rt patch before trying it.
You'll need to make sure CONFIG_PREEMPT_RT=y in your kernel .config to
enable realtime preemption, and don't forget to check that CONFIG_TMPFS=y
or jackd won't perform properly. From 2.6.13 onwards, also make sure
CONFIG_HZ=1000 if using x86 CPU(s).
A good (but slightly dated) overview of the -rt patch is available
here. There is also a
kernel.org -rt WIKI.
Multiple/Dual Core CPUs
There were initially problems with using AMD dual core CPUs.
Normally the most efficient way for applications like jackd to get precise
timing information is to use the CPU's Time Stamp Counter (TSC). In the current
dual-core CPUs it's possible for the two TSCs to drift apart, so if consecutive
timer reads don't occur on the same TSC things can get very confused.
There's a good explanation of the problem
here.
JACK 0.102.20 onwards included a fix which allowed
jackd to work without using the TSC if an AMD x2 CPU
was being used.
The next generation of dual-core AMD64 CPUs will probably have invariant TSCs,
but these aren't going to appear for a while.
Recent kernels no longer attempt to synchronise TSCs on multiple cores, which
works around the problem in the meantime.
The issue did not affect multiple single-core AMD64 CPUs, as the TSCs on these
could be synchronised properly by the kernel.
There can be problems with SMP kernels and the -rt
patch. Users of multiple CPUs sometimes get better results with a non-rt kernel
(with CONFIG_PREEMPT=y).
This applies to both dual-core and multiple single-core CPUs.
If you are using more than 1GB of RAM it is advisable to configure AMD64
SMP kernels with NUMA support. If you use more than this without NUMA,
strange behaviour may occur (eg. jackd's CPU load running out of control).
You don't need more than 1GB to use a NUMA-enabled kernel , but if you have 1GB
or less RAM now and plan to add more, it's a good idea to use it anyway. Your
distro's generic AMD64 kernels are likely to have NUMA enabled.
Multiple Sound Card Problem
At time of writing, the -rt kernel works with AMD64 with
single sound cards and jackd, but doesn't always work if you're using multiple
sound-cards with ALSA pcm_multi and jackd. The latter can cause xruns regardless
of period size on SMP and lock up completely with single CPUs. If this happens
it's necessary to use a standard (non-rt) kernel with CONFIG_PREEMPT=y instead.
Update: There have been reports that -rt kernels work with AMDx2 dual
core CPUs and pcm_multi with jackd, but so far I have been unable to confirm
this with my own hardware.
User Privileges
Normally only the root user can run programs with realtime scheduling.
This applies to all kernels, not just those with the -rt patch.
The most effective way around this for some time was the
realtime-lsm.
This wasn't accepted into the mainline kernel due to security concerns
on multi-user systems, but this isn't usually an issue on an audio workstation.
It is still widely used on older systems, but no longer works with
kernels from 2.6.24 onwards.
The kernel developers introduced another method,
rlimits, which is usable from 2.6.13 onwards (it actually appeared in 2.6.12
but it didn't work until 2.6.13 due to a bug). It's a little harder to set up
than realtime-lsm, but Jonathan Woithe's
set_rlimits program makes it relatively
painless, or if your distro uses a recent version of PAM you can configure
that to set up rlimits. There's a good explanation of how to do that
here. Performance should be the same as with realtime-lsm except
that rlimits will not allow you to hog 100% of the CPU (it limits it to around
90%). Note that realtime-lsm and rlimits can not both be used at the same time.
Realtime Group Scheduling
This was introduced around 2.6.24. It allows control over how much CPU time
is allowed to realtime groups by setting period and run times via the /proc/sys
interface. The default values are zero, ie. no realtime scheduling is allowed.
It was reported to work in 2.6.26, but is broken in 2.6.28. It can be disabled
in the kernel configuration by turning off group scheduling
(CONFIG_GROUP_SCHED=n) in the general setup section. This allows PAM and
rlimits to work normally.
Note for Debian Users
Debian is a solid and reliable distro, but the downside of this is that it
often lags behind others in introducing new software.
For example, I was unable to set realtime privileges using PAM and
/etc/security/limits.conf in Debian 4.0. I used the realtime-lsm module
instead, with a 2.6.20 kernel. Since upgrading to Debian 5.0 (Lenny) I now
have PAM and /etc/security/limits.conf working successfully. Another problem
is that recent versions of jackd need to be compiled with
the --enable-ancient-libc option in order to work with Debian 4.0, but this is
no longer necessary with 5.0.