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.
Desktop Environment
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 "[]"
BIOS/Firmware
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 the “default” way intel handles CPU performance, unless you really want to go down that rabbit hole
Process priority (permission-based)
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)
Hardware I/O buffering
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
}
Power (tuned and profiles)
On Fedora/RHEL,
tunedandtuned-ppdcontrol global power configuration profiles. They replacepower-profile-daemonservice, although configuration profiles still reference “ppd” here and there.They control
- power profile hints (UI “profile” selector - but only a hint)
- cpu governor (the actual CPU frequency bias control)
- couple of other settings
They allow for custom profiles, but there are very useful pre-builts such as
- throughput-performance (corresponds to default “performance” ppd profile)
- balanced (corresponds to default “balance” ppd profile)
tuned-adm list
- 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)
Enable PERFORMANCE tuned/ppd profile in GNOME Power Mode selector
(naturally, with all of the above, incurs power consumption / thermal penalty)
Services
Disabling unnecessary services (goes without saying) but there are some main “offenders”:
a) plocate-updatedb - search indexer
b) cups - printer daemon
c) journald persistency (rsyslog equivalent) - set to volatile (incurs audit dmesg penalty) this one’s is more of a disk write optimization
d) any *.timer service units non-essential (equivalent to scheduled tasks)
Note that some services include *.socket, *.service and *.timer unit configuration files (editable by hand), but generally, *.service files are the main configuration.
When in doubt, use
systemctl edit $SOMESERVICE".service"
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
(Removed section on multichannel drum routing; misplaced and incorrect information)
Sanity check
Apart from Ardour having its’ own SanityCheck tool to tell you if your system configuration meets minimum values for sustained workflow, I need to mention couple of things that are not so obvious
Ardour handles graph and policy/connections for the audio/MIDI backend internally
This means you should avoid external applications that create persistent backend patches (Jack, Pipewire graph nodes + connections, aka policy).
Simply patch everything in Ardour, per session, because it sees everything as it is (no internal virtual ports).
With PipeWire, there is a term thrown around called “pro-mode”. As far as I know, this simply means not connecting the main inputs/outputs to two different hardware devices.
This makes sense, since each interface (builtin or external) has its own clock, and it’s neither a good idea in general, nor will it help the backend or Ardour.
That said, there are cases where you would, for example, output everything to a Bluetooth speaker array for surround mixing, but that’s another story.