Hi @Kristian_Amlie and @TakTik,
Because I use also Linux (Mint) with Renoise 3.53, I have reproduced the same to look into the logs if I get the same. I got the following:
**
”Renoise LOG> Player: 4 threads enabled. 4 CPUs are available.
Renoise LOG> System: Changing a threads priority to ‘-1’ FAILED (error: 22)!
Renoise LOG> System: Changing a threads priority to ‘-1’ FAILED (error: 22)!
Renoise LOG> System: Changing a threads priority to ‘-1’ FAILED (error: 22)!
Renoise LOG> System: Changing a threads priority to ‘-1’ FAILED (error: 22)!"**
Error 22 = EINVAL, which stands for “Invalid Argument”. Because Renoise was attempting to set its real-time audio threads to a maximum priority value (likely 99, or its internal representation -1).
My system rejected this request, deeming the value of 99 an “invalid argument”, because the system’s actual maximum allowable real-time priority was lower (specifically 78 in my configuration).
So, I was also looking behind this problem. And I did the following:
In the config.xml, (which you can find in your /home folder, and then the .config/Renoise folder), there is a line with this content “UseRealTimePriority”. This line is at the bottom of the config file, so you won’t search long. 
I changed it from true to false, so I got UseRealTimePriority “false”.
Then I started Renoise again in the commandline with the following command:
sudo chrt -r 78 su myusername -c “/usr/local/bin/renoise”
I reproduced the above suggestion: changing Multi CPU/Core from 4 to 1, and back to 4 (my system is a quadcore). And the error 22 is gone. And also no error 1 or what ever.
The number 78, is the priority of the “pw-data-loop” thread. Which I got from the Top output (top is a commandline program to see the PID’s and priorities).
So if you use top in the commandline, you can find out what the PID’s are with the command pgrep pipewire, because I use pipewire and jack by pipewire. Use the PID’s output you get from the pgrep command, with the top command, and you can see what the priority’s of the processes are.
For example ‘Top -Hbp 1673,1674’.
Important to know, maybe, is that I have early solved many latency problems with the program RTCQS. All the red flags are gone, one is still there but not relevant (about to not use a boot partition, but you can ignore that. I already use the normal /home folder to store audio files from Renoise).
So, the “PR” value of the pw-data-loop process is now -21. Without running Renoise, after the system boots up. The process called “module-rt” is still “PR” +21, but that is not a problem, because Pipewire is in realtime mode now, which the value of “-21” shows.
I also want to mention, I have added the following lines in the /etc/security/limits.conf file. Which are the following:
@audio - rtprio 99
@audio - memlock unlimited
@audio - nice -10
But in fact, the @audio nice command is not needed if you start renoise in the commandline with the sudo CHRT command. Make sure you have added yourself to the audio group. You can do that with the command: sudo usermod -a -G audio yourusername.
Also, make sure that the following is added to the /etc/pam.d/login file. The line:
“session required pam_limits.so”, must be there. It ensures that the settings in limits.conf (like rtprio 99 or nice -10) are loaded and applied to your user session.
Everything is now without any error when I reproduce the error from TS. Of course, with changing anything on the system, log out and in to apply the changes in the config files and or reboot.
I hope I have helped a bit. (edit: I have wrote the above extended, with things which are meant for other users, or other people who run into this problem. Of course I understand you both are already known with the Linux system, and everything behind it. I also wrote it to show what the process was, and how I have solved it. It might get some insights for the developers of Renoise)
