Arch Linux User Repository

This application has a custom license "All rights reserved"

It can be installed for personal use, but cannot be included in commercial products without the explicit permission of developer.

Before running rtapp for the first time or after an upgrade, take a look at the config file located at /etc/rtapp/rtapp.conf and make sure the defaults are OK.

The old configuration file is saved automatically after an upgrade to /etc/rtapp/rtapp.conf.pacsave

To start rtapp you must first start the systemctl timer: systemctl start rtapp.timer

Then you can enable the service at boot: systemctl enable rtapp.timer

rtapp.timer will call rtapp.service in /usr/lib/systemd/system

rtapp will check the priority of audio applications every 60 seconds. If you want to change this please edit OnUnitActiveSec in /usr/lib/systemd/system/rtapp.timer

RTAPP Rtapp will monitor every minute applications defined in APPLICATIONS and will give FIFO priority defined in MAX_PRIORITY It can be configured in 3 modes: manual: the applications priority will have the value set in MAX_PRIORITY manualdec: same as manual but the priority will decrease by one step from the first to the last application auto: the value will be a step (RTIRQ_PRIO_DECR) under the minimum value of priority set by rtirq (this value depends on the number of items in RTIRQ_NAME_LIST and the number of audio hardware connected to the same USB bus) autodec: same as auto but the priority will decrease by one step from the first to the last application

Example:

---

Here you can list the applications that you want to give realtime priority

APPLICATIONS="jackd mpd hqplayer hqplayerd RoonAppliance RoonBridge sox mediacenter24 networkaudiod deadbeef a2jmidid ardour-5.12.0 rosegarden audacity"

Maximum value MAX_PRIORITY for application priority

MAX_PRIORITY="90"

MODE="autodec"

---

For the variables RTIRQ_PRIO_DECR, RTIRQ_PRIO_HIGH, RTIRQ_PRIO_DECR, RTIRQ_NAME_LIST see rtirq documentatio and rtirq configuration file /etc/rtirq.conf

RTAPP is designed for working with rtirq enabled: systemctl enable rtirq

RTSTATUS rtstatus will show the status of irq and applications realtime priorities.

RTCARDS It is very useful for checking if your audio card is sharing IRQ with another device since it is showing the Vendor and Product names (cat /proc/interrupts instead would be useless because it will not show cards names)

RTTEST rttest will show the latency of your system using first only cyclictest (STANDARD TEST) and after both hackbench and cyclictest (STRESS TEST). The package rt-tests is a dependency.

This application has a custom license "All rights reserved"

It can be installed for personal use, but cannot be included in commercial products without the explicit permission of developer.

Before running rtapp for the first time or after an upgrade, take a look at the config file located at /etc/rtapp/rtapp.conf and make sure the defaults are OK.

The old configuration file is saved automatically after an upgrade to /etc/rtapp/rtapp.conf.pacsave

To start rtapp you must first start the systemctl timer: systemctl start rtapp.timer

Then you can enable the service at boot: systemctl enable rtapp.timer

rtapp.timer will call rtapp.service in /usr/lib/systemd/system

rtapp will check the priority of audio applications every 60 seconds. If you want to change this please edit OnUnitActiveSec in /usr/lib/systemd/system/rtapp.timer

RTAPP Rtapp will monitor every minute applications defined in APPLICATIONS and will give FIFO priority defined in MAX_PRIORITY It can be configured in 3 modes: manual: the applications priority will have the value set in MAX_PRIORITY manualdec: same as manual but the priority will decrease by one step from the first to the last application auto: the value will be a step (RTIRQ_PRIO_DECR) under the minimum value of priority set by rtirq (this value depends on the number of items in RTIRQ_NAME_LIST and the number of audio hardware connected to the same USB bus) autodec: same as auto but the priority will decrease by one step from the first to the last application

Example:

---

Here you can list the applications that you want to give realtime priority

APPLICATIONS="jackd mpd hqplayer hqplayerd RoonAppliance RoonBridge sox mediacenter24 networkaudiod deadbeef a2jmidid ardour-5.12.0 rosegarden audacity"

Maximum value MAX_PRIORITY for application priority

MAX_PRIORITY="90"

MODE="autodec"

---

For the variables RTIRQ_PRIO_DECR, RTIRQ_PRIO_HIGH, RTIRQ_PRIO_DECR, RTIRQ_NAME_LIST see rtirq documentatio and rtirq configuration file /etc/rtirq.conf

RTAPP is designed for working with rtirq enabled: systemctl enable rtirq

RTSTATUS rtstatus will show the status of irq and applications realtime priorities.

RTCARDS It is very useful for checking if your audio card is sharing IRQ with another device since it is showing the Vendor and Product names (cat /proc/interrupts instead would be useless because it will not show cards names)

RTTEST rttest will show the latency of your system using first only cyclictest (STANDARD TEST) and after both hackbench and cyclictest (STRESS TEST). The package rt-tests is a dependency.

Ok, I will fix this as soon as possible.

rtirq configuration moved from /etc/conf.d/rtirq to /etc/rtirq

0.6.7 Updated rtapp.conf

that makes sense (as a very quick test, i guess). I wonder though, rather than suggesting the c-state flags, maybe it would be worthwhile to offer suggestions that are less (potentially) harmful/dangerous? Personally, I would never give someone that advice, as I've done tests and watched within just a few minutes of torturing my system that I have gotten dangerously high cpu temp using intel_idle.max_cstate=0...then, I imagine leaving it that way for hours, or being someone who isn't monitoring sensors. O_o I mean there are better ways to improve latency/determinism on -rt, then using the c-state flags. Examples; using cpu affinity and cpu isolation, disabling hyper-threading, etc... Steven Rostedt has a pretty good talk on youtube discussing some of this stuff; https://www.youtube.com/watch?v=wAX3jOHHhn0 ... It doesn't get super-specific, but does give a nice overview, while also dispelling some of the myths surrounding PREEMPT_RT systems... another option is to limit some of the deeper c-states, while not setting it to =0, which might be a nice compromise for some people. Another option that could be used (in combination with limiting c-states) is to tweak intel_idle a bit, as Clear Linux does; https://github.com/nine7nine/linux-rt-plus/blob/master/linux-rt_plus/0109-intel_idle-tweak-cpuidle-cstates.patch personally, i dont think that the intel_idle.max_cstate=0 flag is needed, if you have tuned your system/apps for RT. It's cost outweighs it's benefit, imho.

Substantially I agree with you... My little test is very useful when I must quickly check realtime systems just after installation. Moreover, good audio systems must have very few applications running (and eventually I must check only audio ones). I would add something more. Using hqplayer with oscilloscope test there is also one more check: the sound. If the system has some problems the sound output will have dropouts or noises. This can happen also with async dacs if the processor is not up to the task, with the numbers given by the various tests apparently good. For absolutely max processor latency performance (if PC has an absolutely very good cooling system) I can add intel_idle.max_cstate=0 processor.max_cstate=0 idle=poll intel_pstate=enable to kernel line (not good in the summer...)

@blackhole - ya, i have rt-tests installed already and I was the person/maintainer who introduced tuna into Archlinux/AUR (and packaged it's deps.) before I handed over the package to jhernberg... I'll take a look at hqplayer, but I'm pretty sure that I already have better test-cases to be running with hackbench/cyclictest. I have a few scripts kickin around that launch highly multi-threaded apps (using rtprios) and/or videos in sequences, etc...

@blackhole - I'll take a look at the rtcheck again tmrrw. Sounds good, if it is fixed. :-) about STRESS TEST: I'm fairly familiar with hackbench and cyclictest (i've been using them for years), so I understand the results ~ That's not the problem. The problem is that your stress test is artificial and gives a false impression of what the system's max: latency is going to be in real world usage. For example; throw nvidia driver into the mix - open multiple videos in a browser and watch what happens.. your max: latency will likely spike giving you no latency guarantees or determinism whatsoever ...another example, introduce other CPU intensive RT tasks into the mix or launch a VM...again, your max: latency will likely spike/increase... cyclictest and hackbench are great, but you have to run them for hours and hours with other stuff going on to have any idea of what your system is really capable of on -rt... about: intel_idle.max_cstate=0 - ya, it will reduce latency, since ur avoiding going into deeper c-states ~ but i'm not sure that's really a great solution to be recommending to people. It can also be a great way to cook your CPU, if ur unlucky or not paying attention.

For a more complete "latency" stress test (this is not a simple cpu load test) I suggest to install tuna and and rt-tests and launch bash -c "cyclictest -t1 -n -p99 -i100 -o10 -v | oscilloscope -s1000 >/dev/null" and at the same time launch hqplayer with PCM --> DSD upsampling