Short backstory:
I've been evaluating u-he synths (Hive seems to be the winner) and trying to optimize my linux system in regards to minimizing xruns.
I've applied some system optimizations as stated within these sources:
- http://subversion.ffado.org/wiki/IrqPriorities
- https://wiki.archlinux.org/index.php/Professional_audio
- https://forum.cockos.com/showpost.php?p ... count=1824
The important bits are the following:
1) Installed package realtime-privileges and added myself to the realtime group.
This created the following:
Code: Select all
~ cat /etc/security/limits.d/99-realtime-privileges.conf
@realtime - rtprio 98
@realtime - memlock unlimited
(an alternative way, using the audio group, seems to be the following: http://subversion.ffado.org/wiki/UsingJ ... scheduling)
2) Established a certain IRQ priorization order.
Running
Code: Select all
ps -eLo rtprio,cls,pid,pri,nice,cmd | grep "FF" | sort -r
This list shows all processes that are scheduled with "SCHED_FIFO" (indicated by "FF" part) (related to realtime priority scheduling):
- kernel stuff: highest priority things that seem to need to be there
- priorization (ex-/implicitly set):
- 95: rtc (not sure if this is still needed)
- 92: the IRQ associated with the USB port my audio interface is connected to (Motu 624)
- 70: jack daemon (set via priority parameter)
- 65: Reaper (DAW); implicitly set by itself
- the rest: all the other things that should be of lower realtime priority
All this to make sure the sound interface, jack and the DAW (in that order) are of higher importance than anything else (apart from kernel stuff).
This should help in avoiding xruns, which would happen if the audio interface or jack don't get adequat processing resources in time when they need it.
Using a program called _htop_ we can see all processes associated with Reaper:
For this I've switched to tree view ('t') and selected the reaper process and all its child processes ('c') (press 'h' for help; 'U' to unselect).
Just note that there are already a bunch of child processes in a project without any loaded VSTs.
Loading non u-he VSTs:
If I load a non u-he synth (i.e. Cadmium; also tried Redux and OBDX), a couple more child processes are created:
All those child processes not previously marked "yellow-ish" are new.
Listing all realtime scheduled processes with the "ps -eLo ..." command from above gives as no change compared to before,
which is how it should be. Regardless of any VST loaded we want our soundcard and jack to be of higher priority.
Loading u-he VSTs:
If I only load a u-he VST (in this case Hive Rev 8296), I get the following in 'htop':
Once again a bunch of new child processes.
Now let's list all realtime scheduled processes with the "ps -eLo ..." command from above;
Many of those newly created child processes are of highest user realtime priority "98" (in regards to highest for user; see start of post).
Therefore these rank above the sound interface and jack, which is not what we want in regards to realtime priorization (avoiding xruns).
Even worse: Loading more VST instances creates more such child processes, which in this case are all declared of higher importance than
the sound interface and jack.
Further tests:
- other u-he synths: same behaviour can be observed with Diva (rev: 8272) and Podolski (1.2.1)
- other DAWs: same behaviour can be observed with Bitwig (2.5.0) and Ardour (5.12). So it doesn's seem to be DAW related (or every DAW does it wrong...).
Final thoughts:
Maybe I'm wrong here and I have a flaw in my understanding of realtime priorization. Feel free to correct me.
Or maybe this really is a strange behaviour by the current u-he linux VSTs, which might actually provoke xruns on
systems that are set up this way in regards to realtime priorization.
Further background information:
- using manjaro linux (5.0.7-1-MANJARO #1 SMP PREEMPT)
- Reaper (5.974)
@u-he: Is all of this intentional? If so, what's the reasoning?
@other readers: If you have a system which is optimized in this way, maybe you could run a quick test yourself to verify or disprove this observation.