Supernova "cannot raise thread priority" (kubuntu studio)

1

Hi all, I’m still relatively new to linux and especially linux audio so my hope is that there is maybe some simple thing that I don’t yet know about that would fix this. Also mine isn’t some super personal arch setup but pretty much a straightforward ubu studio install.

system specs

Operating System: Ubuntu Studio 24.04
KDE Plasma Version: 5.27.12
KDE Frameworks Version: 5.115.0
Kernel Version: 6.17.0-22-generic (64-bit)
Graphics Platform: Wayland
Processors: 6 × Unknown Type, 6 × AMD Ryzen 5 7530U with Radeon Graphics
Memory: 14.5 Gio of RAM

SC 3.15, Built from branch ‘develop’ [21347a84c]

Supernova runs ok-ish for lighter loads but when it boots I get warnings:

Warning: cannot raise thread priority
Warning: cannot raise thread priority
Warning: cannot set thread affinity of audio helper thread
(3x)

Is this to be expected and ignored, and if not, what can I do about it?
I already ran rtcqs and did all the changes recommended there except the spectre/meltdown related one; the user running sclang and scsynth is in the audio group, and am going over the list here System configuration [Linux-Sound]…

2

If you don’t see a file that looks like that in /etc/security/limits.d, you can add it yourself. It will have exacly the same effect. For example, something like /etc/security/limits.d/95-audio.conf with:

@audio - rtprio 95 
@audio - memlock unlimited 
@audio - nice -19

Then make sure the user is a member of that group: sudo usermod -aG audio "$USER"

1 Like
3

Thanks! I did that again, and I noticed that in my audio.conf the nice-related line was commented out; so I uncommented that. Also the file contained a hint saying “If you want to enable/disable realtime permissions, rundpkg-reconfigure -p high jackd2”… so I did that too. Restarted, and now indeed the Warning: cannot set thread affinity of audio helper thread has disappeared (either because of the nice change or the other command). So that’s good!
But the cannot raise thread priority warning still happens…

EDIT: upon further investigation (looking in the supernova source), I think the warning happens when the user is running pipewire, because supernova won’t distinguish between jack not being able to get rt priorities and jack not running at all. So I guess I have to figure out jack if I want supernova…

4

Did you solve it? I get the same message and my system is configured for RT audio. I’m also using pipewire-jack which routes audio of programs using jack to pipewire.

5

sorry, no real solution yet… it’s a bit beyond my abilities I think.
I figured I wouldn’t bother with jack directly since pipewire also implements jack, and is allegedly the more modern solution… so I spent a few hours trying to come to grips with pipewire(-jack) and wireplumber… but the documentation is not exactly noob-friendly, and while there are options that have to do with rt priority and such, the problem is that I don’t even know which node or object I would have to apply those settings to.

maybe someone like @Spacechild1 would have a better idea of where to start with this one, but I figure this is not an urgent issue.

That said, have you noticed any performance issues compared to scsynth? I haven’t yet compared supernova and scsynth systematically on this machine. Could be interesting going forward whether the limitation is actually relevant.

1 Like
6

Sorry for being a bit late. I can confirm that Supernova is not getting RT priority despite it is configured correctly and perfectly working with scsynth. I didn’t test it, but I guess that this becomes a problem at higher CPU usage.

->->-> Bug tracking with chatGPT

Title:
supernova cannot raise thread priority on Ubuntu 24.04 / PipeWire, while scsynth gets SCHED_FIFO correctly

System:
Ubuntu 24.04
Kernel: 6.17.0-23-generic
Audio: PipeWire / pipewire-jack
SuperCollider version: [insert output of: sclang -v / supernova -v]
Supernova started from SuperCollider with Server.supernova

Problem:
When booting supernova, it prints several times:

Warning: cannot raise thread priority

The server starts and audio works, but all supernova threads remain normal TS scheduling.

Evidence:

  1. Realtime limits are correct:

ulimit -r
95

ulimit -l
unlimited

/proc//limits:
Max locked memory unlimited
Max realtime priority 95
Max realtime timeout unlimited

  1. The user can create realtime processes manually:

chrt -f 70 true
echo $?
0

chrt -f 70 bash -c ‘ps -o pid,cls,rtprio,pri,comm -p $$’

shows:
CLS FF, RTPRIO 70

  1. scsynth works correctly on the same system/session:

ps -Leo pid,tid,cls,rtprio,pri,comm | grep -i scsynth

shows e.g.:

scsynth FF 1
scsynth FF 50
scsynth FF 50

  1. supernova does not:

ps -Leo pid,tid,cls,rtprio,pri,comm | grep -i supernova

shows:

supernova TS -
supernova TS -
supernova TS -
pw-supernova TS -
pw-supernova TS -

  1. Starting supernova manually through chrt does not fix it:

chrt -f 70 supernova -u 57110

supernova still prints:
Warning: cannot raise thread priority

and threads remain TS.

Conclusion:
This does not look like a missing audio group / limits.d / memlock configuration problem, because scsynth obtains SCHED_FIFO correctly and chrt works. It appears specific to supernova, possibly the PipeWire/JACK backend or supernova’s internal thread-priority handling.

Expected:
supernova should obtain realtime scheduling similarly to scsynth, or at least not drop all server/audio threads to TS when RT privileges are available.

1 Like
7

This doesn’t seem to be the problem (see above).