[fixed RNS 3.5.4]: Linux audio thread priorities not set correctly on startup, only when manually updating "Multi Core" value

[Kristian_Amlie]

This issue originally stems from this thread, but I’m resubmitting in a more condensed form.

Environment

OS: Linux
Audio driver: Jack
Renoise version: 3.5.3

To reproduce

1. Start Renoise.
2. Make sure that “Options → Multi Core” is set to more than 1. However, if you change it, shut down Renoise and start it again.
3. Execute this command in a terminal:

   ps -eL -o priority,comm | grep "Audio Slave"
   

Expected behavior

The number in the first column should be negative or “rt”, meaning high priority.

Actual behavior

The number in the first column is positive, meaning low priority.

This is a regression from Renoise 3.4.

Effect

The effect of this is that playback using multiple threads with low period sizes produces a lot of xruns. If only one thread is used, the problem does not occur, since no extra threads are created at all.

Workaround

Changing the Multi Core setting updates the priorities, and they are correct from that point onwards. However, this must be done every time Renoise is started.

[OopsIFly]

Confirmed here. Renoise will create audio engine without realtime priorities using Jack on Renoise 3.5.3/Debian trixie. Changing the CPU core number support in settings will enable realtime priorities, leading to much better dropout stability.

Tested with dblue - tension on quad core 64 frames / 2 periods in jack server synchronous mode. Before changing number of cores in settings will hit many x-runs, after changing the counter stays clear.

Also I found, that loading another song will also reset the priorities, after loading a new song you have to change the number of CPUs used again to reenable realtime priorities.

This command makes the difference more clear, and also shows other related audio threads:

ps -eL -o rtprio,priority,comm | grep -i -e "audio" -e "jack"

[Kristian_Amlie]

Fixed together with this issue.