Realtime priority?
Moderators: MattKingUSA, khz
-
- Established Member
- Posts: 2325
- Joined: Sat Jun 21, 2014 8:37 pm
- Been thanked: 256 times
Re: Realtime priority?
Thanks for the very good explanations.
.59/reaper.... .59 is the hidden folder from where reaper is launched.
I'ts easy and beneficial to start reaper as a command, as I tinker a lot, and can
get reaper to segfault/lock up sometimes when trying to get some pesky windows apps
running. I do a ctrl-alt-F5 a few times every month, but I feel empowered
by having sorted some excellent software for at least basic uses as sound sources
in uncomplicated sessions.
snd_ICE_1712 is my maudio pci card. It is coincidence that it has
the same priority as the motherboard sound chip, snd-hda.
Previously, I had set Reaper buffering prefs to use just one core for using Kontakt,
as there were too many audible dropouts with normal buffer settings.
I think I read that tip at the linux Reaper forum, and it worked. The improvement I perceived
was playing Kontakt, and the response feeling instantaneous, with a lack of dropouts,
and in a session with several other plugins, and couple sequences running
as my band-mates. This with all four i7 3.4 ghz cores available to Reaper.
There are many 'moving targets' here. Wine gets better. Reaper gets better.
Linux kernels get better. System libs get better. Plugins (and their wrappers)
get better. We might get lucky and have a clean slate every few months,
and never even know it I think wine-staging 4.2 arrived at
such a crossroads of good code
.59/reaper.... .59 is the hidden folder from where reaper is launched.
I'ts easy and beneficial to start reaper as a command, as I tinker a lot, and can
get reaper to segfault/lock up sometimes when trying to get some pesky windows apps
running. I do a ctrl-alt-F5 a few times every month, but I feel empowered
by having sorted some excellent software for at least basic uses as sound sources
in uncomplicated sessions.
snd_ICE_1712 is my maudio pci card. It is coincidence that it has
the same priority as the motherboard sound chip, snd-hda.
Previously, I had set Reaper buffering prefs to use just one core for using Kontakt,
as there were too many audible dropouts with normal buffer settings.
I think I read that tip at the linux Reaper forum, and it worked. The improvement I perceived
was playing Kontakt, and the response feeling instantaneous, with a lack of dropouts,
and in a session with several other plugins, and couple sequences running
as my band-mates. This with all four i7 3.4 ghz cores available to Reaper.
There are many 'moving targets' here. Wine gets better. Reaper gets better.
Linux kernels get better. System libs get better. Plugins (and their wrappers)
get better. We might get lucky and have a clean slate every few months,
and never even know it I think wine-staging 4.2 arrived at
such a crossroads of good code
Re: Realtime priority?
I was just following this video which I saw posted in another thread here because it's for Manjaro KDE which is what I'm using:https://youtu.be/vgrqMv3Lzfk?t=708 And I did this part where he added some lines to /etc/security/limits.conf. He said this is necessary because although there was an audio group and that the user was added to it by default, it wasn't configured properly.
and then I realised, in /etc/security/limits.d there is a file called 99-realtime-privileges.conf which contains this
I notice that in the video, Unfa only has 10-gcr.conf in this directory while I have
I don't know where 99-realtime-privileges.conf came from but I'm thinking it might conflict with the lines I just added to limits.conf. Anyone have any ideas? I'm not sure if I'm about to screw my system up.
Code: Select all
# audio group
@audio - rtprio 95
@audio - memlock unlimited
Code: Select all
@realtime - rtprio 98
@realtime - memlock unlimited
Code: Select all
10-gamemode.conf 10-gcr.conf 10-gcr.conf.pacnew 99-realtime-privileges.conf
Last edited by Death on Sat May 02, 2020 3:29 pm, edited 1 time in total.
- lilith
- Established Member
- Posts: 1698
- Joined: Fri May 27, 2016 11:41 pm
- Location: bLACK fOREST
- Has thanked: 117 times
- Been thanked: 57 times
- Contact:
Re: Realtime priority?
You can comment the lines in the file /etc/security/limits.conf out. Then the values from /etc/security/limits.conf/99-realtime-privileges.conf should be taken. You can check with the realtimeconfig script if it works.
Re: Realtime priority?
Ah cool. That sounds like a good way to check I installed realtimeconfigquickscan-git from the package manager but I don't know how to run it. I did check the github page for it but the only commands I saw there were for downloading and installing it as far as I could tell. Can you help? Cheers.
- lilith
- Established Member
- Posts: 1698
- Joined: Fri May 27, 2016 11:41 pm
- Location: bLACK fOREST
- Has thanked: 117 times
- Been thanked: 57 times
- Contact:
Re: Realtime priority?
The command to run it is the last one of these lines:Death wrote: ↑Sat May 02, 2020 3:40 pmAh cool. That sounds like a good way to check I installed realtimeconfigquickscan-git from the package manager but I don't know how to run it. I did check the github page for it but the only commands I saw there were for downloading and installing it as far as I could tell. Can you help? Cheers.
Code: Select all
git clone git://github.com/raboof/realtimeconfigquickscan.git
cd realtimeconfigquickscan
perl ./realTimeConfigQuickScan.pl
Re: Realtime priority?
Ah right. I didn't realise the repo installed it to a different place so that's why it didn't work.
Anyway, here's the output:
Would I be right in thinking it's not working? I'm not sure exactly what I should be seeing here..
Cheers.
Edit: Ok. I ran it again by using limits.conf instead and I got some different results:
A difference I noticed is
Does that mean it's working?
Also, I found a Manjaro thread (https://forum.manjaro.org/t/qjackctl-co ... d/122579/4) and it seems that '99-realtime-privileges.conf'' would've been created by the realtime-privileges package I have installed as a dependency for another program (I don't know which). Thing is, there's no 'realtime' group as far as I can tell so that config file probably didn't do anything seeing as each line starts with '@realtime'.
Anyway, here's the output:
Code: Select all
== GUI-enabled checks ==
Checking if you are root... no - good
Checking filesystem 'noatime' parameter... 5.6.7 kernel - good
(relatime is default since 2.6.30)
Checking CPU Governors... CPU 0: 'performance' CPU 1: 'performance' CPU 10: 'performance' CPU 11: 'performance' CPU 12: 'performance' CPU 13: 'performance' CPU 14: 'performance' CPU 15: 'performance' CPU 2: 'performance' CPU 3: 'performance' CPU 4: 'performance' CPU 5: 'performance' CPU 6: 'performance' CPU 7: 'performance' CPU 8: 'performance' CPU 9: 'performance' - good
Checking swappiness... 60 - not good
** vm.swappiness is larger than 10
set it with '/sbin/sysctl -w vm.swappiness=10'
See also: http://linuxmusicians.com/viewtopic.php?f=27&t=452&start=30#p8916
Checking for resource-intensive background processes... none found - good
Checking checking sysctl inotify max_user_watches... < 524288 - not good
increase max_user_watches by adding 'fs.inotify.max_user_watches = 524288' to /etc/sysctl.conf and rebooting
For more information, see http://wiki.linuxaudio.org/wiki/system_configuration#sysctlconf
Checking access to the high precision event timer... not readable - not good
/dev/hpet found, but not readable.
make /dev/hpet readable by the 'audio' group
For more information, see http://wiki.linuxaudio.org/wiki/system_configuration#hardware_timers
Checking access to the real-time clock... not readable - not good
/dev/rtc found, but not readable.
make /dev/rtc readable by the 'audio' group
For more information, see http://wiki.linuxaudio.org/wiki/system_configuration#hardware_timers
Checking whether you're in the 'audio' group... yes - good
Checking for multiple 'audio' groups... no - good
chrt: failed to set pid 0's policy: Operation not permitted
Checking the ability to prioritize processes with chrt... no - not good
Could not assign a 80 rtprio SCHED_FIFO value. Set up limits.conf.
For more information, see http://wiki.linuxaudio.org/wiki/system_configuration#limitsconfaudioconf
Checking kernel support for high resolution timers... found - good
Kernel with Real-Time Preemption... not found - not good
Kernel without 'threadirqs' parameter or real-time capabilities found
For more information, see https://wiki.linuxaudio.org/wiki/system_configuration#do_i_really_need_a_real-time_kernel
Checking if kernel system timer is high-resolution... found - good
Checking kernel support for tickless timer... found - good
== Other checks ==
Checking filesystem types... ok.
** Set $SOUND_CARD_IRQ to the IRQ of your soundcard to enable more checks.
Find your sound card's IRQ by looking at '/proc/interrupts' and lspci.
Cheers.
Edit: Ok. I ran it again by using limits.conf instead and I got some different results:
Code: Select all
== GUI-enabled checks ==
Checking if you are root... no - good
Checking filesystem 'noatime' parameter... 5.6.7 kernel - good
(relatime is default since 2.6.30)
Checking CPU Governors... CPU 0: 'performance' CPU 1: 'performance' CPU 10: 'performance' CPU 11: 'performance' CPU 12: 'performance' CPU 13: 'performance' CPU 14: 'performance' CPU 15: 'performance' CPU 2: 'performance' CPU 3: 'performance' CPU 4: 'performance' CPU 5: 'performance' CPU 6: 'performance' CPU 7: 'performance' CPU 8: 'performance' CPU 9: 'performance' - good
Checking swappiness... 60 - not good
** vm.swappiness is larger than 10
set it with '/sbin/sysctl -w vm.swappiness=10'
See also: http://linuxmusicians.com/viewtopic.php?f=27&t=452&start=30#p8916
Checking for resource-intensive background processes... none found - good
Checking checking sysctl inotify max_user_watches... < 524288 - not good
increase max_user_watches by adding 'fs.inotify.max_user_watches = 524288' to /etc/sysctl.conf and rebooting
For more information, see http://wiki.linuxaudio.org/wiki/system_configuration#sysctlconf
Checking access to the high precision event timer... not readable - not good
/dev/hpet found, but not readable.
make /dev/hpet readable by the 'audio' group
For more information, see http://wiki.linuxaudio.org/wiki/system_configuration#hardware_timers
Checking access to the real-time clock... not readable - not good
/dev/rtc found, but not readable.
make /dev/rtc readable by the 'audio' group
For more information, see http://wiki.linuxaudio.org/wiki/system_configuration#hardware_timers
Checking whether you're in the 'audio' group... yes - good
Checking for multiple 'audio' groups... no - good
Checking the ability to prioritize processes with chrt... yes - good
Checking kernel support for high resolution timers... found - good
Kernel with Real-Time Preemption... not found - not good
Kernel without 'threadirqs' parameter or real-time capabilities found
For more information, see https://wiki.linuxaudio.org/wiki/system_configuration#do_i_really_need_a_real-time_kernel
Checking if kernel system timer is high-resolution... found - good
Checking kernel support for tickless timer... found - good
== Other checks ==
Checking filesystem types... ok.
** Set $SOUND_CARD_IRQ to the IRQ of your soundcard to enable more checks.
Find your sound card's IRQ by looking at '/proc/interrupts' and lspci.
Code: Select all
Checking the ability to prioritize processes with chrt... yes - good
Also, I found a Manjaro thread (https://forum.manjaro.org/t/qjackctl-co ... d/122579/4) and it seems that '99-realtime-privileges.conf'' would've been created by the realtime-privileges package I have installed as a dependency for another program (I don't know which). Thing is, there's no 'realtime' group as far as I can tell so that config file probably didn't do anything seeing as each line starts with '@realtime'.
- lilith
- Established Member
- Posts: 1698
- Joined: Fri May 27, 2016 11:41 pm
- Location: bLACK fOREST
- Has thanked: 117 times
- Been thanked: 57 times
- Contact:
Re: Realtime priority?
Ah... ok, then just leave it uncommented and you should be fine. Likely the other file has no function at all. I've never seen that 99 file.
Re: Realtime priority?
Ok. I will do for now.
I think it's an Arch thing by the looks of it. As far as I can tell, when realtime-privileges was installed, it should've added a realtime group to which I should've been added - I guess that didn't work. Maybe it'd be better for me to create that group and add myself to it, I'm not sure. But if it looks good as it's configured now, I'll leave it alone I try to avoid messing with these things as much as possible!
Still, Cadence shows 80 for Realtime priority which is what I set it to the other day when I noticed it was at 10. I wonder what the hell that's referring to and if it's actually doing anything or just useless... God damn audio setups on Linux eh! Haha
Cheers.
Edit: Yeh it looks like Arch is different so I probably should do it by making and adding myself to the realtime group: https://wiki.archlinux.org/index.php/Re ... management
-
- Established Member
- Posts: 1392
- Joined: Thu Oct 11, 2018 4:13 pm
- Has thanked: 168 times
- Been thanked: 247 times
Re: Realtime priority?
The realtime-privileges package likely has created a realtime group. You can see a list of all groups withDeath wrote:Thing is, there's no 'realtime' group as far as I can tell ...
Code: Select all
$ cat /etc/group
Code: Select all
$ cat /etc/group | grep realtime
You can add your user to the realtime group with
Code: Select all
$ sudo usermod -a -G realtime <your-user>
Re: Realtime priority?
Thanks for the reply. It's cool though, I think I've got it setup right now
I tried to create the realtime group but it already existed so I added myself to it. For some reason that uninstalled realtime-privileges and removed the config file so I reinstalled that and the config file was recreated also. I verified I was in the realtime group and ran that script again which appeared to have much better results this time - It looks like there's only a few things it suggests to change now. So yeh, it seems like Arch does things a little differently but I've taken notes I can refer back to in future.
I think I just levelled up my Linux haha It's always a nice feeling..
Also, I noticed that Cadence has reported 0 Xruns so far. Usually I'll get about 15 just from starting Jack, so that's cool! However, it seems like my DAW is stuttering a bit more easily now. I'll have to test more.. And of course, the Realtime priority setting in Cadence still shows 80 which makes no sense to me.. 2 steps forward, one step back? At least I'm moving forward over all
I tried to create the realtime group but it already existed so I added myself to it. For some reason that uninstalled realtime-privileges and removed the config file so I reinstalled that and the config file was recreated also. I verified I was in the realtime group and ran that script again which appeared to have much better results this time - It looks like there's only a few things it suggests to change now. So yeh, it seems like Arch does things a little differently but I've taken notes I can refer back to in future.
I think I just levelled up my Linux haha It's always a nice feeling..
Also, I noticed that Cadence has reported 0 Xruns so far. Usually I'll get about 15 just from starting Jack, so that's cool! However, it seems like my DAW is stuttering a bit more easily now. I'll have to test more.. And of course, the Realtime priority setting in Cadence still shows 80 which makes no sense to me.. 2 steps forward, one step back? At least I'm moving forward over all
- lilith
- Established Member
- Posts: 1698
- Joined: Fri May 27, 2016 11:41 pm
- Location: bLACK fOREST
- Has thanked: 117 times
- Been thanked: 57 times
- Contact:
Re: Realtime priority?
80 is fine! That's the priority of Jack which should be ~80. You sound card should be set higher (~90-95, but never 99).
Re: Realtime priority?
Ah. I keep getting confused with all the steps I've been through recently. I'll leave it at 80 then! Thanks