System configuration

Note about Kernels >= linux-image-2.6.31
  • Kernels >= linux-image-2.6.31 seems to work pretty good without RT patch, also for realtime pro audio usage. It's not strictly necessary anymore to install a realtime (RT) kernel to get good results. All though the best results are still expected when using a realtime kernel. Try it, test it and decide for yourself.

How do I get an out-of-the-box working Linux audio workstation?

How do I build a realtime audio workstation on Linux?

Quickscan

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

Installing a real-time kernel

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.

Finding out whether you're running an rt kernel

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

Ubuntu

Install the 'linux-image-rt' package (or a specific one, like linux-image-2.6.24-19-rt).

Debian

Manually

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:

Disabling resource-intensive daemons

You should check if the following daemons are running, and if so, consider stopping them:

  • powersaved
  • kpowersave
  • ondemand, especially when your CPU supports frequency scaling, referred to as SpeedStep for Intel CPU's and PowerNow or Cool'n'Quiet for AMD CPU's.

Filesystems

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.

Encryption

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

tmpfs

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 ?

noatime

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.

limits.conf

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

sysctl.conf

Suggested settings for /etc/sysctl.conf:

 fs.inotify.max_user_watches = 524288

audio group

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.

hardware timers

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.

priorities

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.

See also: http://tapas.affenbande.org/wordpress/?page_id=40

And: http://subversion.ffado.org/wiki/IrqPriorities

The dreaded "cannot use real-time scheduling" warning

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.

Linux audio/midi system basic components

  • A typical Linux audio/midi system consists of some basic components. You can find information about it here

How do I set up a Linux audio midi system?

  • Answers you can find here
 
system_configuration.txt · Last modified: 2010/08/15 06:30 by raboof
 
Recent changes RSS feed Creative Commons License Donate Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki