Download the realTimeConfigQuickScan.pl script to automatically analyze your current configuration. This script will make configuration suggestions based on your current setup and link to the relevant section on this page for background information.
Discuss this script at the LinuxMusicians Forum
This section describes installing a real-time ('rt') kernel on an existing Linux distribution. Some distributions contain packages you can install to get an rt kernel, for others you'll need to compile it yourself.
run 'uname -a' to find out which kernel you're running - for example, for my ubuntu machine, this returns:
Linux bird 2.6.24-19-rt #1 SMP PREEMPT RT Wed Jun 18 16:35:41 UTC 2008 i686 GNU/Linux
2.6.24-19-rt is the version number of the currently running kernel. The configuration file with which this kernel was created can usually be found in /boot/config-2.6.24-19-rt. Open it, and check if it has the following characteristics:
CONFIG_HZ_1000=y CONFIG_HZ=1000 CONFIG_PREEMPT_RT=y CONFIG_PREEMPT=y
If you can't find the config file for your kernel, or want to make extra-sure the currently running kernel is okay, read http://rt.wiki.kernel.org/index.php/RT_PREEMPT_HOWTO#Checking_the_Kernel
This step is included in the quickScan
Install the 'linux-image-rt' package (or a specific one, like linux-image-2.6.24-19-rt).
If your distribution isn't any help, you can compile and install an rt kernel manually.
Among others, the following options are recommended:
See these links:
You should check if the following daemons are running, and if so, consider stopping them:
For audio use, it is desirable to use a filesystem that favours few big files over many small files and low-latency over long-term thoughput.
It is said that ReiserFS and fuseblk are bad choices from this perspective, while ext3 is good. ext4 is not recommended with kernels >= 2.6.32 because of possible regression issues.
In any case, it is advisable to mount filesystems with the noatime option enabled.
This step is verified by the Quickscan, but could use more information about which filesystems are suitable.
It won't affect the quality of the audio, but it will change how many tracks the disk can support and because encryption requires CPU, it will affect how much signal processing you can do all of which is a long-winded way of saying “don't do it”
It is useful to mount the 'tmpfs' at /tmp:
mount -t tmpfs none /tmp
or add to /etc/fstab:
none /tmp tmpfs defaults 0 0
See also: http://lowlatency.linuxaudio.org
This step is verified by the Quickscan
— AutoStatic 2010/01/15 09:10 Question: is this step still necessary now that jackd uses /dev/shm ?
Setting the noatime parameter in your fstab reduces the amount of disk I/O (the inode access times are not updated each time a file is read) which could improve the overall performance of your system.
/dev/sda1 / ext3 noatime,errors=remount-ro 0 1
Most modern distributions use either atime or relatime. See the mount manpage for more information on these parameters.
It is advisable to set up your /etc/security/limits.conf properly, for example:
@audio - rtprio 90 # maximum realtime priority @audio - memlock unlimited # maximum locked-in-memory address space (KB)
Setting memlock to unlimited shouldn't be strictly necessary since most apps would work fine with lower values (such as 500000).
However, certain applications have been reported to complain or even to crash with lower values than unlimited.
On the other hand, giving unlimited capability of locking memory can cause buggy applications to temporarily freeze the whole system.
See http://www.linuxmusicians.com/viewtopic.php?f=10&t=2193 for more details.
You could also allow the audio group to renice processes with the help of the limits.conf file, but when using rtprio this is not necessary anymore because rtprio is the best way to tell the scheduler to prioritise audio related processes.
See also: http://linuxmusicians.com/viewtopic.php?f=27&t=392
If you do not use PAM (which is rare), you might want to use set_rlimits instead
Suggested settings for /etc/sysctl.conf:
fs.inotify.max_user_watches = 524288
It is generally good practice to have an 'audio' group, and add any users that should be allowed to perform audio tasks to this group. This prevents some interference from non-audio-processes with audio tasks.
To verify you're in the 'audio' group, run the 'groups' command.
Remember, after adding yourself to new groups, you need to log out and back in again.
(be careful when adding an 'audio' group to your system: most systems come with a pre-configured 'audio' group, and do not warn you when you add another group with the same name, leading to much confusion).
This step is verified by the Quickscan.
MIDI sequencers and such will benefit from being able to use hardware timers like the real-time clock (/dev/rtc) or the High Precision Event Timer (/dev/hpet). Make sure the 'audio' group has read permissions on it.
A simple 'chown' might not be persistent across reboots - to make the change last, create a new 40-timer-permissions.rules file in /etc/udev/rules.d with the following lines:
KERNEL=="rtc0", GROUP="audio" KERNEL=="hpet", GROUP="audio"
… and reboot. See also: https://bugs.launchpad.net/ubuntu/+source/udev/+bug/306458
This step is verified by realTimeConfigQuickScan.pl.
For rtprio, higher values mean higher priority. For nice, lower values mean higher priority. You can list threads and their priorities with ps axHo user,lwp,pid,rtprio,ni,command or ps -eLo pid,cls,rtprio,pri,nice,cmd | grep -i “irq”
Most applications take care of running some threads with higher rtprio when possible themselves, like JACK with the realtime option set. JACK's watchdog has a higher prio than jackd itself so choose a sensible priority value for JACK (70 for example), bearing in mind also that sound devices get a priority in the 80-90 range.
You can also set rtprio and scheduling settings manually using the chrt command-line tool, which should come with most distributions nowadays, or use the rtirq init script.
When starting JACK it exits with a warning that looks like this:
cannot use real-time scheduling (FIFO at priority 10) [for thread 720017136, from thread 720017136] (1: Operation not permitted)
This means that the current user is not allowed to run JACK in real-time mode. A quick fix would be to disable the real-time option in QjackCtl. If you want to get rid of this warning and use JACK in real-time mode you will have to modify your limits.conf file and make sure you're a member of the audio group.