Difference between revisions of "Realtime process management"
m (further reading)
m (→JACK: link adjust)
|Line 98:||Line 98:|
See: [[Pro Audio]]
See: [[Pro Audio]]
Revision as of 15:47, 14 October 2009
Realtime for Joe Sixpack
While most processors are powerful enough to play a dozen video or at least audio streams at once, it is possible that another thread hijacks your processor for just half a second to complete another task. This results in short interrupts in audio or video streams. It can also happen that your video/audio streams get out of sync. While it is annoying for casual music listener, a content producer, composer or video editor simply can't accept this problem since it interrupts his/her workflow. The pretended simple solution is to make the audio and video processes a higher priority. But as most users know, Joe Sixpack 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. It makes sense that the average user cannot steal too much power from processes which are necessary just to keep the system running. This is especially important on multiuser machines. Many realtime desires are limited to single user machines, so this aspect of security is not as critical as it seems. By the same time it should be made sure that the user can really control the priorities only and cannot affect other parts of system configuration which are controlled by root only.
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 - nice -10 @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