Glitch free / XRUN free stable workflow at 256 samples

After days of trying to troubleshoot power/performance/glitching/xruns/memory issues on Fedora Linux Workstation (43, kernel 7), I have finally managed to allow for a musical workflow without worrying abouth technicalities. It took a lot of tweaking and reverting tweaks and searching. Here’s my checklist.
(intel core i7 - 4 physical, 4 virtual cores (4x2)).

I believe this could be translated to other systems easily, since this is a standard / generic minimal nowadays.

GNOME/Wayland fractional scaling (anything other than 100, 200, 300x magnification)

  • a source of MEMORY LEAK, which makes XWayland GUI interaction fill up shared memory, memfd and swap very quickly
  • disable and avoid at all costs
gsettings set org.gnome.mutter experimental-features "[]"

Intel TurboBoost - UEFI/BIOS firmware lock

  • make sure it’s CHECKED
  • incurs energy penalty
  • coupled with kernel flag (only if firmware unlocked)
echo 0 | sudo tee /sys/devices/system/cpu/intel_pstate/no_turbo

(0 = turbo on)

  • even with 8 cores, TurboBoost is “default” way intel handles CPU performance, unless you really want to go down that rabbit hole

rtprio

sudo vi /etc/security/limits.d/99-realtime.conf
sudo usermod -aG pipewire $(whoami)
sudo usermod -aG audio $(whoami)
# 99-realtime.conf
@pipewire   -  rtprio     95
@pipewire   -  memlock    unlimited
@pipewire   -  nice       -10

@audio      -  rtprio     95
@audio      -  memlock    unlimited
@audio      -  nice       -10
  • 70 is not enough
  • 95 is minimum (empirical)

Pipewire latency/buffer hard set

  • allows Ardour to default to managable tracking/recording latency (256 samples I can handle)
  • reasoning: changing latency/buffer on an already running JACK/Pipewire server might desync and/or destabilize the stream, resulting in unexpected behavior
vi ~/.config/pipewire/pipewire.conf.d/10-buffer-limit.conf
# 10-buffer-limit.conf
context.properties = {
    default.clock.quantum = 256
    default.clock.min-quantum = 128
    default.clock.max-quantum = 512
}

tuned

  • on Fedora/RHEL, tuned and tuned-ppd global power configuration

It controls

  1. power profile hints (UI “profile” selector - but only a hint)
  2. cpu governor (the actual CPU frequency bias control)
  3. couple of other settings

Allows for custom profiles, but there are a lot of pre-built such as

  1. throughput-performance (corresponds to default “performance” ppd profile)
  2. balanced (corresponds to default “balance” ppd profile)
  • custom profiles are defined under
    /etc/tuned/profiles/$PROFILEDIR/tuned.conf
  • this custom profile can reference a script if you need additional /proc /sys flags to be set (cpupower custom changes, loops, and whatever else scripts do)
    /etc/tuned/profiles/$PROFILEDIR/script.sh (convention)
  • enabling PERFORMANCE tuned profile (GNOME Power Mode selector)
    (naturally, with all of the above, incurs power consumption / thermal penalty)

Disabling unnecessary services (goes without saying) but

a) plocate-updatedb - search indexer
b) cups - printer daemon
c) journald persistency (rsyslog equivalent) - set to volatile (incurs audit dmesg penalty)
d) any *.timer service units non-essential (equivalent to scheduled tasks)

Multitasking

  • Web browsers consume resources - do you need them in the creative flow?
  • Accordingly, disabling radio antennaes (wifi in particular) is not going to hurt

If I missed anything, I’ll add.

Right now, on 9.7.2, for the first time, I got a GUI-glitch free, minimum XRUNS at 256 sample buffer at 48 kHz, with 50% average load in a session with

  • 3 synthesizer plugins
  • 1 FluidSynth plugin (ACE)
  • 1 MPC drum sampler plugin
    (all with elaborate GUIs)
  • 2 reverb busses
  • 2 audio busses for multichannel drum routing

Note on multichannel drum routing:

  • pins coming out of mulitchannel drum sampler plugin are 16 stereo pairs
  • pins coming out of the plugin SLOT should be manually configured (bypassing Strict I/O)
  • the issue - if there isn’t 1-1 mapping between slot output pins and plugin outputs, the mapping is “normalized” - 32 plugin pins mapped to 4 outputs need to be patched in the following way:
    ------- plugin output 1,2 → slot output 1-4
    ------- plugin output 3,4 → slot output 2-3

otherwise, linear 1-1 mapping outputs 1,3 to slot output 1-2, and 2,4 to outputs 3-4, resulting in signal duplication (VST3 quirk? plugin quirk?)

That’s about it!

1 Like

Thanks! But do you use this with MIDI tracks or in a live setup? And disabling necessary services, I use to do that but not anymore, haven’t run into issues since. Just did some overdubs with a buffer of 32 samples/frames period at 48kHz using Ardour’s monitoring and the recordings contain zero xruns. And I didn’t disable WiFi, on my laptop it doesn’t get in the way of the USB audio interface.

From my own experience I’ve found setting the CPU governor to performance, disabling SMT and setting the CPU DMA latency to lowest in the Ardour performance preference window helps the most. And make sure your audio interface is connected to a USB bus that isn’t too crowded, best would be if it has the bus for itself.