Could be off-topic but I wanted to leave this somewhere. Thank you so much for everything you’ve done. Renoise has been a continued source of joy for me for over 10 years now and I am deeply grateful to everyone that was involved in its creation. Thank you, as well, for keeping it alive through bugfixes such as this one. I’m sure I’m not the only one who feels incredibly grateful for what Renoise has given them.
#!/usr/bin/env bash
#
# script from Robbert Yabridge
#
# Some applications like to spawn high priority realtime threads. This can cause
# latency spikes during DAW usage.
thread_blacklist_re='^(webrtc_audio_mo|InotifyEventThr)$'
process_blacklist_re='^/usr/lib/(firefox|signal-)'
# To make it easier to see what's going on and which threads we're going to
# reschedule, we'll print all realtime threads with their thread names and the
# first part of their command, and we'll mark the threads we're going to
# reschedule.
realtime_threads=$(ps hxH -u "$USER" -o tid:30,rtprio:30,comm:30,command |
# HACK: Since thread names can contain spaces and ps doesn't have a way to
# specify a delimiter, we'll hack around this a bit by making every
# every column fixed width and then manually adding tabs. This would
# have been neater with some proper parsing, but, oh well...
# We'll also truncate the last column for readability's sake.
sed -E 's/^(.{30}) /\1\t/;
s/(\t.{30}) /\1\t/;
s/(\t.{30}) /\1\t/;
s/ +//g;
s/(\t[^ ]+)( [^\t]+)?$/\1/' |
awk -F$'\t' '($2 >= 5) {
if ($3 ~ THREAD_RE || $4 ~ PROCESS_RE) { printf "x\t" } else { printf " \t" }
print $2 "\t" $1 "\t" $3 "\t" $4;
}' THREAD_RE="$thread_blacklist_re" PROCESS_RE="$process_blacklist_re" |
column -ts$'\t')
need_rescheduling=$(echo "$realtime_threads" | awk '$1 == "x" { print $3 }')
echo "$realtime_threads"
if [[ -z $need_rescheduling ]]; then
echo -e "\nNothing to do here, modify the blacklists if needed."
else
echo -e "\nSetting all marked threads to SCHED_OTHER..."
echo "$need_rescheduling" | xargs --no-run-if-empty -n1 chrt -po 0
fi
Running this makes it appear that Audio Slave has a higher priority than /usr/bin/pipewire. My naive guess is that this seems like it could be a problem, but what do you think?
@tkna: For me the priorities are back to what they were in Renoise 3.4. How the priority is calculated exactly, I do not know, since it is five levels below jack (jackd: 95, renoise: 90), but it’s in acceptable range I think. Only taktik can answer what the detailed logic is.
Is this a good way to display real-time threads? The ps options are complex and I don’t fully understand them, but I tried to use relatively straightforward options here.
The main audio thread (created by Renoise when using ALSA) uses the highest possible RT priority. So does the MIDI output scheduler thread, because it is, well, also time-critical.
The audio worker threads use a slightly lower RT priority, so the MIDI scheduler can interrupt them if necessary.
It is unlikely to cause problems if the audio slaves have a higher priority than Pipewire, because the Pipewire thread (if I understand it’s role correctly) kicks off and then waits for the audio worker threads to finish their jobs. The worker threads don’t run constantly.
I don’t have enough knowledge to fully understand it yet, but at least for general use, is that okay?
I often run 4 to 8 instances of Renoise during live performances, sometimes pushing the BPM and LPB to their limits and overworking them. Currently, Audio Slave seems to have a priority 5 lower than pipewire, and there don’t appear to be any issues with xrun or latency. So, just to be safe, I’ll try running it with the above shell script and see how it goes.
Good to have bugfixes!