REAPER for Linux

From CockosWiki

(Difference between revisions)

Revision as of 21:26, 7 August 2017

This article is about using the native REAPER for Linux build.

Beta builds

REAPER for Linux builds are considered "pre-beta" or similar - use at your own risk! Download from: https://www.landoleet.org

Currently supported platforms

x86_64
ARMv7 (Raspberry Pi 3)

Installation

To install REAPER for Linux, download one of the builds from https://www.landoleet.org, extract the tarball, and run the "reaper5" executable. REAPER for Linux uses the path ~/.REAPER/ for its configuration state.

The stock build should run (hopefully) on any modern Linux system, it requires libstdc++.so.5, and by default requires GTK+ v3 to be installed, though if you recompile libSwell.so https://landoleet.org/dev/libSwell-roll-your-own.txt, you can also target GTK+ v2.

Supported audio backends

ALSA (required, no MIDI support yet)
JACK (optional, supports MIDI)
PulseAudio (optional, no MIDI support, high latency)

A short explanation of the various backends: https://wiki.linuxaudio.org/wiki/linux_audio_overview

User extensions

Install in ~/.REAPER/UserPlugins

SWS - binary build here: https://landoleet.org/dev/reaper_sws...0af0201.tar.xz - Build instructions: https://github.com/reaper-oss/sws/wi...-SWS-Extension
ReaPack - download one of the .so files: https://github.com/cfillion/reapack/releases - build instructions: https://github.com/cfillion/reapack/...ster/README.md

Features not officially supported on Linux (yet)

Elastique
Windows VSTs
LV2, LADSPA & DSSI plugins
JACK transport

Plug-in support

REAPER on Linux supports the builtin plug-ins (REA/JS), as well as Linux VST2/3.

For a comprehensive list of Linux VSTs, see: http://linux-sound.org/linux-vst-plugins.html

Linux system configuration

None is required for REAPER to run, but for lower latency there are a few considerations.

Linux low latency audio is based on POSIX real time threads. A thread of a higher priority will preempt threads of lower priority and will run until it is finished. The idea is to order the priority of the threads, so that the soundcard interrupt handling thread has the highest priority, then in order of descending priority, REAPER's audio threads, hardware IRQ handlers (like screen, disk io, net, etc, and lowest of all REAPER's other threads and the rest of the programs running on the system.

Kernels

Kernels can be built to schedule threads in different ways. The relevant ones for low latency audio are capable of preempting a running thread to run another one. If the kernel isn't configured for this, REAPER can still run but will need bigger buffers. The suitable kernels are commonly referred to as lowlatency and realtime.

A lowlatency kernel can preempt threads. The realtime kernel in addition tries to maximize the surface of the kernel that can be preempted, so it achieves a lower kernel scheduling latency.

This is the time it takes the kernel to start running a thread, a lower scheduling latency means less possible audio dropouts at low latency settings and high system load. Given a deadline of 1.45ms, if it takes the kernel 2ms to schedule the audio processing threads, there is a dropout.

The only relevant difference is that the realtime kernel can achieve a lower scheduling latency than the lowlatency kernel.

To see what type of kernel is running, use the command "uname -a", if the output contains "PREEMPT" it is a lowlatency kernel, and if "PREEMPT RT" it is a realtime kernel.

There can be many causes for a high scheduling latency, Some worth mentioning (in no particular order) are: a misconfigured system, bad hardware, badly programmed kernel modules, CPU power management, faulty hardware timers, SMIs, NMIs, etc.

User privileges

As Linux is a multiuser OS, there are (by default) 2 relevant privileges denied the user, as a malicious user could use them to attack the system:

rtprio - allow the user to run realtime threads
memlock - allow the user to lock code and data into RAM, preventing it from being discarded or swapped out

To be able to schedule realtime threads, the user (or a group the user belongs to) needs to be given "rtprio" rights at login. The max value configurable is 99, but there are some kernel threads running there, so a suggested setting for rtprio is 98.

If the system discards or swaps out RAM (containing REAPER/plugin code/data), it will likely cause a dropout when it needs to be reloaded, thus the reason to give the user the right to "memlock". A suggested setting is unlimited.

To run REAPER with pulseaudio no special configuration is needed
To use REAPER's ALSA backend with the "RT priority" option, "rtprio" privileges are needed
To use REAPER's JACK backend, both privileges are probably neeeded (depending on the JACK configuration)

To check what capabilities the logged in user has, run "ulimit -a".

See this link for more detailed JACK configuration instructions: http://www.jackaudio.org/faq/linux_rt_config.html

Thread priorities

The realtime kernel exports the hardware interrupt handlers to run as threads in user space, as does the lowlatency kernel when booted with the "threadirq" boot flag. This allows the user to manipulate the priorities of the interrupt handlers.

By default the interrupt handlers will run at priority 50, with some kernel house keeping threads at 99 and some software timers at 1.

Setting the thread handling the soundcard or the usb hub IRQ to a high priority (like 95), and the audio threads slightly lower (80) will make sure that they run before most other threads.

Recommended priorities:

95 sound card interrupt handler
80 jackd/or REAPER (ALSA)

Tips and tricks

Low latency checklist

Give the user rtprio and memlock privileges
Install a realtime or lowlatency kernel if not already installed
If using a lowlatency kernel add the "threadirq" boot flag
Set the thread handling the soundcard or USB hub IRQ to priority 95
Set JACK (or REAPER if using the ALSA driver) to use priority 80

Additional plugin support

REAPER has no built in bridge to run Windows VST(i)s. LinVst: https://github.com/osxmidi/LinVst is a well working bridge that uses WINE to host the plug-ins. For discussions regarding running Windows plug-ins on REAPER for Linux, see: https://forum.cockos.com/showthread.php?t=193761

Carla: http://kxstudio.linuxaudio.org/Applications:Carla is another plug-in host, that can host Windows VST(i)s as well as unsupported Linux plug-in formats.

Theming

The generic Windows controls can be themed by editing libSwell.colortheme (in the directory containing the reaper5 executable).

Desktop integration and MIME support

Preliminary Linux Desktop and MIME support at: https://stash.reaper.fm/v/30638/reaper-desktop-support.zip, and instructions at: https://forum.cockos.com/showpost.php?p=1839292&postcount=1686.

IRC

There is a channel dedicated to REAPER on Linux at freenode.org called #reaper-linux.

Main Page > REAPER Documentation

@@ Line 89: / Line 89: @@
 === Thread priorities ===
-The realtime kernel exports the interrupt handlers to run as threads in user space, as does the lowlatency kernel when booted with the "threadirq" boot flag.  This allows the user to manipulate the priorities of the hardware interrupt handlers.
+The realtime kernel exports the hardware interrupt handlers to run as threads in user space, as does the lowlatency kernel when booted with the "threadirq" boot flag.  This allows the user to manipulate the priorities of the interrupt handlers.
-By default the hardware interrupt handlers will run at priority 50, with some kernel house keeping threads at 99 and some software timers at 1.
+By default the interrupt handlers will run at priority 50, with some kernel house keeping threads at 99 and some software timers at 1.
 Setting the thread handling the soundcard or the usb hub IRQ to a high priority (like 95), and the audio threads slightly lower (80) will make sure that they run before most other threads.