lefteros_by SomniusX
EL ↗Say hello

LEFTEROS / PERSONAL NOTES

Crackling audio in Renoise on Omarchy: the realtime fix, without rtkit

22 October 2026 / Lefteris Iliadis / SomniusX

Crackling audio in Renoise on Omarchy: the realtime fix, without rtkit

I installed the Renoise 3.5.4 demo on Omarchy (Arch + Hyprland, PipeWire 1.6.9) and playback crackled. Regular clicks all through the audio, clear enough that a screen recording picked them up. It turned out the problem was not Renoise at all: nothing on the system had realtime scheduling, not even PipeWire. So this applies to anyone doing audio on Omarchy, with any DAW. Here is the short version first, then the why.

TL;DR: the fix

sudo pacman -S realtime-privileges
sudo gpasswd -a $USER realtime
# do NOT install rtkit on this setup (see below)
sudo reboot

A logout is not enough, more on that below. After the reboot, in Renoise go to Preferences > Audio, switch the device from ALSA to JACK and set 48000 Hz. That was it, the audio played perfectly.

The symptom

Renoise logged this on every start, and popped it up as a dialog too:

Failed to create a RealTime priority thread for ALSA. Will create a non RT thread instead... It is highly recommended to use RealTime priority audio threads with ALSA AND Jack

Why it happened

  • ulimit -r was 0, I was not in any realtime group, and rtkit was not installed. PipeWire itself logged mod.rt: RTKit error: org.freedesktop.DBus.Error.ServiceUnknown at boot and ran its audio threads as normal processes. On my Omarchy install, nothing got realtime out of the box.
  • On top of that, Renoise was using the ALSA default device (PipeWire's ALSA plugin) at 44100 Hz, while the PipeWire graph runs at 48000 Hz (clock.allowed-rates [48000]), with a small buffer: 3 periods of 288 frames, 864 frames in total, about 20 ms. Resampling, a tiny buffer and no priority: clicks.

The rtkit trap

My first try was the usual Arch recipe: rtkit plus realtime-privileges, and my user in the realtime group. The group gives rtprio 98, unlimited memlock and nice -11 through /etc/security/limits.d/99-realtime-privileges.conf.

Surprise: with rtkit installed, Renoise got killed a few seconds after start. It showed the RT warning dialog, then "Killed", exit code 137 (SIGKILL). I reproduced it without Renoise:

aplay -D default -t raw -f S16_LE -r 44100 -c 2 -d 3 /dev/zero

Also Killed, 137, about a second after rtkit logged "Successfully made thread ... RT at priority 1". So on this setup every ALSA client got killed the moment rtkit made its thread realtime. I did not prove the exact kernel mechanism; the kernel logs nothing about it. The likely explanation is the realtime CPU-time limit that comes with rtkit's grants, but that is a likely explanation, not a proven one.

Removing rtkit (sudo pacman -R rtkit) and keeping realtime-privileges brought the aplay test back to exit 0.

The lingering gotcha

Logging out and back in did nothing. Lingering was on for my user (loginctl show-user $USER -p Linger says yes), and with lingering the user services do not restart on logout, so PipeWire kept running with the old limits. A full reboot was needed.

How to check it worked

ulimit -r
ps -L -o cls,rtprio,comm -p $(pidof pipewire)
aplay -D default -t raw -f S16_LE -r 44100 -c 2 -d 3 /dev/zero; echo $?

After the reboot I got ulimit -r = 98, the PipeWire data-loop threads running FF (SCHED_FIFO) at priority 88 and 83, and the aplay test exiting with 0.

Renoise settings

  • Preferences > Audio: device JACK, 48000 Hz. pipewire-jack provides /usr/lib/libjack.so.0, so JACK clients talk straight to PipeWire, no separate JACK server. With the graph rate matched, no resampling either.
  • Optional, for lower latency: start it with PIPEWIRE_QUANTUM=256/48000 renoise. Don't force a global quantum for the whole graph just for one app.
  • Renoise keeps its settings in ~/.config/Renoise/V3.5.4/Config.xml and rewrites it on exit, so change things in the GUI, not in the file.

Extra: Renoise and AI agents

A side note, since I was in there anyway. Renoise ships a Lua scripting API: the install has /usr/local/share/renoise-3.5.4/Scripts/Docs and Scripts/Types (type definitions for the Lua language server), so tools (.xrnx) can script the song. It also has a built-in OSC server, off by default, on UDP port 8000 in this install's Config.xml.

On top of that there is a community tool, Renoise MCP (ReMCP) by kunitoki: an MCP (Model Context Protocol) server that runs inside Renoise and exposes the song API to MCP clients like Claude Desktop or Claude Code, so you can ask an assistant in plain language to help compose, arrange, mix and edit. Install is copy the tool into Renoise's Tools, start Renoise, start the server from the Tools menu. The author's forum post calls 0.1 an early prototype: not stable, missing features and docs. I have not tried it deeply yet, but it is worth a look. With the Lua API docs and MCP you can also give an agent your own instructions and skills for your workflow.