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).
From 2.6.14 onwards, make sure you turn off CONFIG_PARANOID_GENERIC_TIME
in your .config - it's useful for debugging but has some overhead.
A good overview of the -rt patch is available
here.
A good article on compiling and tuning realtime kernels is available
here.
Multiple/Dual Core CPUs
There are potential 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.
The next generation of dual-core AMD64 CPUs will probably have invariant TSCs,
but in the meantime the kernel (and JACK) developers have been busy trying to
minimise the problem. It is possible to work around it with the boot option
idle=poll, but this wastes CPU cycles even when the system is doing nothing.
JACK 0.102.20 onwards
includes a fix which allows
jackd to work without using the TSC (and without idle=poll) if an AMD x2 CPU
is being used.
This issue does not affect multiple single-core AMD64 CPUs, as the TSCs on these
can be synchronised properly by the kernel.
There can be issues 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 is likely (eg. jackd's CPU load runs out of control).
You don't need more than 1GB to use a NUMA-enabled kernel , so if you have 1GB
or less RAM now but plan to add more, it's a good idea to use it anyway
(your distro's AMD64 SMP kernels are likely to have NUMA enabled by
default).
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. 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's still widely used for audio work.
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. You can either set up realtime-lsm (regardless of how new or old
your version of PAM is) or configure a recent version of PAM for realtime,
but not both at once. Performance of the two methods should be the same except
that rlimits will not allow you to hog 100% of the CPU (it limits it to around
90%).
You should use realtime-lsm or rlimits with any kernel, not just
those with the -rt patch. Note that realtime-lsm is deprecated, and is
no longer usable with very recent kernels. It still works fine on 2.6.20.
Debian 4.0 (Etch) Update: At time of writing, I've been unable to set
realtime privileges using PAM and /etc/security/limits.conf in Debian 4.0.
I'm using the realtime-lsm module with a 2.6.20 kernel.