Hello,
I know that Jack has realtime priorities but is it worth to increase the process priority of a Jack aware application ? Does it have an effect on audio processing stability (e.g reducing XRuns) ?
Kind Regards,
Laurent
Is it worth using nice or renice command with Jack aware applications ?
Moderators: MattKingUSA, khz
Re: Is it worth using nice or renice command with Jack aware applications ?
I think it is mainly important that Jack itself runs at high priority which can be set, for example, in QJackCtl, in Setup->Advanced tab. In general you can check your config with this script: https://github.com/raboof/realtimeconfigquickscan
- sunrat
- Established Member
- Posts: 923
- Joined: Wed Jul 22, 2020 2:08 pm
- Has thanked: 151 times
- Been thanked: 245 times
Re: Is it worth using nice or renice command with Jack aware applications ?
nice was suggested years ago but is now considered irrelevant. Obligatory link to LinuxAudio system config wiki page - https://wiki.linuxaudio.org/wiki/system_configuration
I also found that, for Intel processors, disabling C-states can be beneficial. I mentioned it in my Debian Bullseye setup guide -viewtopic.php?f=19&t=22793
I also found that, for Intel processors, disabling C-states can be beneficial. I mentioned it in my Debian Bullseye setup guide -viewtopic.php?f=19&t=22793
-
- Established Member
- Posts: 1392
- Joined: Thu Oct 11, 2018 4:13 pm
- Has thanked: 168 times
- Been thanked: 247 times
Re: Is it worth using nice or renice command with Jack aware applications ?
The short answer is no.
If you look at htop there are two relevant columns PRI and NI -- the priority and the nice. At first glance it seems to work backwards. The lower the PRI value the higher the priority. nice makes PRI higher which makes the priority lower. To give a process a higher priority negative nice values are used.
Realtime threads have the highest priority and so have a negative PRI value. nice doesn't work on realtime threads.
Looking at Guitarix -- there is a process in orange with a PRI of 20. That is the GUI, the app, non-JACK stuff. Then there is a Guitarix thread in green with
a PRI of -81. That is the JACK realtime thread doing the audio processing. I set the priority of JACK in QjackCtl at 85, which results in a PRI of -86 for jackdbus as I'm using jackdbus, and a priority of -81 for JACK apps.
If you look at htop there are two relevant columns PRI and NI -- the priority and the nice. At first glance it seems to work backwards. The lower the PRI value the higher the priority. nice makes PRI higher which makes the priority lower. To give a process a higher priority negative nice values are used.
Realtime threads have the highest priority and so have a negative PRI value. nice doesn't work on realtime threads.
Looking at Guitarix -- there is a process in orange with a PRI of 20. That is the GUI, the app, non-JACK stuff. Then there is a Guitarix thread in green with
a PRI of -81. That is the JACK realtime thread doing the audio processing. I set the priority of JACK in QjackCtl at 85, which results in a PRI of -86 for jackdbus as I'm using jackdbus, and a priority of -81 for JACK apps.
Re: Is it worth using nice or renice command with Jack aware applications ?
The answer is probably application specific.
For Pianoteq, the working threads spawned from the main app run with real-time priority, but I still got the random/occasional x-runs. I was able to get better results by setting the main Pianoteq app to a nice value of -20. The command line is kinda janky, but it works.
Notes: GVFS
I suspect I wouldn't need to use 'nice' if the gvfs daemons could be killed properly, but they're almost impossible to kill. I have a kill all batch script, but opening a web browser or terminal re-spawns everything, damn you d-bus, systemd and gnome! I'm using XFCE but Gnome crap has burrowed it's way into everything. It's the one optimization I can't figure out how to do. Unfortunately I'm running on a not so well-known SOC (Odroid N2+) - so switching to a distro without GVFS isn't an option right now.
For Pianoteq, the working threads spawned from the main app run with real-time priority, but I still got the random/occasional x-runs. I was able to get better results by setting the main Pianoteq app to a nice value of -20. The command line is kinda janky, but it works.
Code: Select all
sudo nice --20 sudo -u root taskset -c 2,3,4,5 '/opt/Pianoteq 7 STAGE/arm-64bit/Pianoteq 7 STAGE' --fullscreen
I suspect I wouldn't need to use 'nice' if the gvfs daemons could be killed properly, but they're almost impossible to kill. I have a kill all batch script, but opening a web browser or terminal re-spawns everything, damn you d-bus, systemd and gnome! I'm using XFCE but Gnome crap has burrowed it's way into everything. It's the one optimization I can't figure out how to do. Unfortunately I'm running on a not so well-known SOC (Odroid N2+) - so switching to a distro without GVFS isn't an option right now.