Realtime process management
Realtime for Normal users
While many recent processors are powerful enough to play a dozen video or audio streams simultaneously, it is still possible that another thread hijacks the processor for half a second to complete another task. This results in short interrupts in audio or video streams. It is also possible that video/audio streams get out of sync. While this is annoying for a casual music listener; for a content producer, composer or video editor this issue is much more serious as it interrupts their workflow.
The simple solution is to give the audio and video processes a higher priority. However, while normal users can set a higher nice value to a process, which means that its priority is lower, only root can set lower values and start processes at a lower nice value than 0. This protects the normal user from underpowering processes which are essential to the system. This can be especially important on multiuser machines.
Realtime and Realtime is not the same
Realtime is a synonym for a process which has as much capabilities to run in time without being interrupted by any other process. A couple of things can make it drop cycles nevertheless. Maybe the processor is running out of juice or another process with an even higher priority steals too many CPU-cycles. There is a scaling of realtime quality. The main aspect we are dealing with is the soft realtime. If a box runs out of power and the video editor's playback starts to drop frames, the process must be made different like rendering out the preview file so that it can be played without problems. Hard realtime is usually not "desired" but "needed". An example could be made for car's ABS. This can not be "rendered" and there is no second chance.
A Small History to Understand The Problem
There have always been efforts to make it easier for the user to achieve realtime capabilities from the kernel. A lot of patches were floating around the web. As of generation 2.6 there was an addon module available called realtime-lsm. It required CAPABILITY build as module and was only to handle by the more experienced user since the absence of CAPABILITY in the kernel in case that neither capability nor realtime-lsm was loaded can cause trouble.  As of kernel-2.6.12, the so called rlimits patch has been accepted in the mainstream kernel and is now the desired way to provide normal users with realtime capabilities.
Power is Nothing without Control
The realtime-lsm module granted the right to get higher capabilities to users belonging to a certain UID. The rlimit way works similar, but it can be controlled graduated finer. There is a new functionality in PAM which can be used to control the capabilities on a per user or a per group level. In the current version (0.80-2) these values are not set correctly out of the box and still create problems. With PAM you can grant realtime priority to a certain user or to a certain user group. PAM#s concept makes it imaginable that there will be ways in the future to grant rights on a per application level. But this is not yet possible.
The necessary settings for realtime
First of all, make sure your kernel is compiled with "preemptible kernel" settings. As /boot/kconfig26 tells you, the standard Arch Linux kernel is configured that way. This warning just goes out to all the selfcompilers. Secondly, you need a PAM>0.80 or 0.79-3(that was patched). The last I can confirm working was 0.80-2 from "testing". Just note that the names for the variables in limits.conf have changed from 0.79 to 0.80! Now edit your /etc/security/limits.conf. Arch Linux comes with sane standards for users from the @audio group. Make sure that you are a member of it and you are mainly done. The standard settings are enough to get jack-server running with hydrogen or ardour. For some other applications it might be necessary to redefine the values for rt_prio from 65 to 80 or even higher!
The following settings work for me also with ardour:
@audio - rtprio 70 @audio - memlock 250000
See: Start X at Boot
To activate the settings in /etc/security/limits.conf you have to use a PAM-enabled login method/manager. Nearly all graphical login managers are pam-enabled. You can check that by looking for the related line/file in /etc/pam.d:
~$ grep pam_limits.so /etc/pam.d/*
If you get nothing, you are whacked. But you will, as long as you have a login manager (and now policykit). The line we are looking for is:
session required pam_limits.so
See: Automatic VC Login
If you prefer to not have a graphical login, you still have a way. You need to edit the pam stuff for su (from coreutils):
# /etc/pam.d/su ... session required pam_limits.so
Source (thanks to jochen and dunc): http://bbs.archlinux.org/viewtopic.php?pid=387214
See: Pro Audio