Set rtprio for Reaper

[profquad]

Hi, I've noticed my many many xruns are all "REAPER was not finished" and checked with ps, and it says /opt/REAPER/reaper is running with rtprio 5
I've done basically everything in the holy handbook rtcqs, besides the dangerous one and swappiness and dma latency rules bc it was running way too hot with no performance gain.
One thing I could never get tho is CONFIG_PREEMPT_RT=y

grub already has
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash threadirqs"
GRUB_CMDLINE_LINUX=""

I'm wondering if maybe the second line undoes the prior?

I also don't know if this is relevant to rtprio. Tried chrt but it turned my mouse off somehow... could be related to me using TrackPoint in Mint, which seems to have some priority issues anyways.

In any case, I'm looking for a good way to change rtprio of specific programs or paths (for some yabridged VSTs) but everything I find online is just people saying "I changed it" without saying how?
Sorry, still pretty green, and appreciate any advice!

Using liquorix 6.6.2-1 Mint Cinnamon 21.1

[Impostor]

You don't need to set rt priority for applications afaik. Set it for Jack only, so only audio processing gets priority. Otherwise you may end up giving GUIs rt priority, which may not be that great an idea.

[sunrat]

Liquorix is not an RT kernel so won't have CONFIG_PREEMPT_RT=y

I'm wondering if maybe the second line undoes the prior?

No it doesn't.

I never set rtprio for applications, only for audio group which is set up automatically by install of jackd. /etc/security/limits.d/audio.conf:

Code: Select all

@audio   -  rtprio     95
@audio   -  memlock    unlimited

It could possibly be a storage i/o problem if your disk access is too slow. Are you recording on the same disk as system?

I just set up a new Debian Bookworm with Liquorix 6.6.6 on my old i5-6500 system and got over 97% in xruncounter, an amazing result. Pretty much only set it with rtcqs showing OK for everything except swappiness. Haven't tried audio applications yet so jury is still out.

[profquad]

You don't need to set rt priority for applications afaik. Set it for Jack only, so only audio processing gets priority. Otherwise you may end up giving GUIs rt priority, which may not be that great an idea.

Well, I'd like to! haha. I just don't know how. running:

Code: Select all

chrt -f 90 /opt/REAPER/reaper

but still get a priority of 5.

Been asking ChatGPT, it suggested a /etc/systemd/system/reaper.service idea that, after some prodding, still didn't work. Ended up with variations on:

Code: Select all

[Unit]
Description=Reaper Digital Audio Workstation

[Service]
ExecStartPre=/usr/bin/chrt -f 90 $(pgrep -o reaper)
ExecStart=/full/path/to/reaper

[Install]
WantedBy=default.target

but chrt would fail every time:

Code: Select all

× reaper.service - Reaper Digital Audio Workstation
     Loaded: loaded (/etc/systemd/system/reaper.service; disabled; vendor preset: enabled)
     Active: failed (Result: exit-code) since Wed 2023-12-13 14:22:01 EST; 10s ago
    Process: 15706 ExecStartPre=/usr/bin/chrt -f 90 $(pgrep -o reaper) (code=exited, status=127)
        CPU: 1ms

Dec 13 14:22:01 Madlad systemd[1]: Starting Reaper Digital Audio Workstation...
Dec 13 14:22:01 Madlad chrt[15706]: chrt: failed to execute -o: No such file or directory
Dec 13 14:22:01 Madlad systemd[1]: reaper.service: Control process exited, code=exited, status=127/n/a
Dec 13 14:22:01 Madlad systemd[1]: reaper.service: Failed with result 'exit-code'.
Dec 13 14:22:01 Madlad systemd[1]: Failed to start Reaper Digital Audio Workstation.

ChatGPT couldn't figure out why, so now I'm asking ChatIRL

Liquorix is not an RT kernel so won't have CONFIG_PREEMPT_RT=y

does that mean rtprio has no meaning?

Code: Select all

I never set rtprio for applications, only for audio group which is set up automatically by install of jackd. /etc/security/limits.d/audio.conf:
[code]@audio   -  rtprio     95
@audio   -  memlock    unlimited

@audio group is already set up and high priority.

It could possibly be a storage i/o problem if your disk access is too slow. Are you recording on the same disk as system?

2.8Gb/sec benchmark just now, ext4 noatime

I just set up a new Debian Bookworm with Liquorix 6.6.6 on my old i5-6500 system and got over 97% in xruncounter, an amazing result. Pretty much only set it with rtcqs showing OK for everything except swappiness. Haven't tried audio applications yet so jury is still out.

ahh xruncounter sounds like exactly what I was looking for earlier.
yeah, swappiness seems irrelevant, have 24 gigs of ram, 8th gen i5-8250U, Lenovo T480s. I do wonder if the U series CPU is why the DMA latency step immediately brought my core temp into the 90s.

and the third one I don't do is mitigations.. this is my daily driver.

This is why I'm so interested in changing the rtprio of reaper directly, so it asks more, but not too much. I've seen people say 50 is a good number for it, and I can tell by all the

JackEngine::XRun: client = REAPER was not finished, state = Running
JackAudioDriver::ProcessGraphAsyncMaster: Process error

xruns I get that 5 is not high enough, and from I just don't know how to set it. Anyone know?

[Impostor]

Code: Select all

chrt -f 90 /opt/REAPER/reaper

but still get a priority of 5.

All threads? If I chrt -f 78 muse4 then one thread has rtprio 5, one has rtprio 39, the rest has rtprio 78.
Chrt apparently sets the maximum rtpriority for a process.

Code: Select all

[Unit]
Description=Reaper Digital Audio Workstation
[Service]
ExecStartPre=/usr/bin/chrt -f 90 $(pgrep -o reaper)
ExecStart=/full/path/to/reaper

but chrt would fail every time:

You're running chrt on a process-id which doesn't exist yet?

[autostatic]

Well, I'd like to!

Setting a real-time priority for a DAW itself won't make any difference. You want to set the priority of IRQ threads and JACK, if in use.

Been asking ChatGPT, it suggested a /etc/systemd/system/reaper.service idea that, after some prodding, still didn't work

ChatGPT is recommending nonsense. A systemd service that runs Reaper as root is just plain silly.

does that mean rtprio has no meaning?

Liquorix is a low-latency kernel (CONFIG_PREEMPT=y) so it accepts the threadirqs kernel option which allows you to set priotity of IRQ threads.

2.8Gb/sec benchmark just now, ext4 noatime

ChatGPT is parroting https://wiki.linuxaudio.org/wiki/system ... ilesystems here. But with modern SSD's there's very little difference between noatime and relatime (the default).

yeah, swappiness seems irrelevant, have 24 gigs of ram, 8th gen i5-8250U, Lenovo T480s. I do wonder if the U series CPU is why the DMA latency step immediately brought my core temp into the 90s.

I've come across reports that give me the impression these kind of processors are probably not the best choice for doing audio production. The U means they're designed for power efficiency and that can cause issues when used for audio (overheating because of poor cooling from laptop vendors, aggressive throttling).

[profquad]

ah yeah... I'm coming to the conclusion the the U in my CPU is the problem.
But today, for no special reason, I can't even to up to 1024 without massive xruns.. Surely something else is going on?
I'm getting really frustrated, it works worse this week than last week.

[sunrat]

You can set minimal idle states, and disabling mitigations (it's a minuscule security risk) can give a serious performance boost for some processors. I set extra kernel options:

Code: Select all

intel_idle.max_cstate=0 processor.max_cstate=1 threadirqs mitigations=off

Liquorix disables P-states and runs performance cpu governor as default.

But why it is worse than last week is a mystery that would be difficult to solve. Check if logs or journalctl show any clues.

[autostatic]

When setting CPU DMA latency option in Reaper (Options - Preferences - Audio - Disable power management if supported) I don't think setting C states as a kernel option is necessary anymore. From what I understood is that if the CPU DMA latency is set to 0 the CPU never idles as it's being put in C0 state.

[bluebell]

You can set minimal idle states, and disabling mitigations (it's a minuscule security risk) can give a serious performance boost for some processors. I set extra kernel options:

Code: Select all

intel_idle.max_cstate=0 processor.max_cstate=1 threadirqs mitigations=off

Liquorix disables P-states and runs performance cpu governor as default.

But why it is worse than last week is a mystery that would be difficult to solve. Check if logs or journalctl show any clues.

Kernel options are a strange thing. On my computers (Core i5 and i7, Kernel 5.15) threadirqs leads to chopped audio.

[sunrat]

Kernel options are a strange thing.

As are all config and tweak options. I think, to get a perfectly running system, one must invoke either magic or voodoo, and perhaps sacrifice a puppy.

On my computers (Core i5 and i7, Kernel 5.15) threadirqs leads to chopped audio.

First report I've heard of that. On my system (i5 6500) it led to a measurable improvement.

[bluebell]

Kernel options are a strange thing.

As are all config and tweak options. I think, to get a perfectly running system, one must invoke either magic or voodoo, and perhaps sacrifice a puppy.

On my computers (Core i5 and i7, Kernel 5.15) threadirqs leads to chopped audio.

First report I've heard of that. On my system (i5 6500) it led to a measurable improvement.

I tried again. It is important to configure /etc/default/rtirq for each computer correctly. So I reached a state where threadirqs doesn't make it worse at least.