Nuisance Warning Line: [ALSOFT] (EE) Failed to set real-time priority for thread: Operation not permitted (1)

[1bardesign]

Reported the following to love2d devs who thought it was more of an issue with openal-soft, so repeating it here.

I get the following warning in console every time launching apps with openal-soft:

[ALSOFT] (EE) Failed to set real-time priority for thread: Operation not permitted (1)

Occasionally, the line appears more than once (maybe per-audio-thread or something?)

Audio still works. I have not measured latency which i presume might be affected.

On a few other issues that have turned up around apparently the following fixes it:

# usermod -G realtime -a $(whoami)

I haven't tried this fix yet; I'll try it soon and report back.

In my opinion, this warning is a nuisance, because it pollutes to the console for something the user in question can't always fix.

I don't believe the affected software is asking for verbose logging or anything of that nature.

I'm on manjaro linux (arch-based); I haven't installed anything else to do with audio, haven't modified my user, and get this warning on multiple machines using software that uses openal-soft for audio.

This hasn't always happened, but I'm not sure when it started happening I'm afraid.

[kcat]

That warning is pretty important, since it indicates the audio thread isn't getting real-time priority and can more easily underrun and/or lag. PulseAudio, PipeWire, and JACK would also not like not getting real-time priority for their audio threads (though they're not usually run in a way where you'd see an error message; they'd just perform non-optimally). Fixing it in a way like you describe is one way to do it. I have been meaning to look into using the rtkit dbus call as a backup when pthread_setschedparam fails, which may be more compatible on modern systems.

But if you know you're not getting real-time priority, and are okay with the potential consequences, you can either set OpenAL Soft to not log any messages (either set the ALSOFT_LOGLEVEL env var to 0, or ALSOFT_LOGFILE to /dev/null), or configure it to not try setting real-time priority (create/edit $HOME/.config/alsoft.conf and add the lines

[general]
rt-prio = 0

). Just remember to unset those when you get real-time priority allowances, or if you have rtkit set up and OpenAL Soft starts using it.

[1bardesign]

Thanks for the various ways to suppress this and for investigating other ways to get access on modern systems.

I understand why the software wants realtime output - but if someone is getting this warning, there's likely a reason they dont have realtime access.

I haven't personally noticed any issues from not having this access for my normal user account on this system; my audio still plays and there aren't any underrun artefacts that i've heard.

I haven't measured latency, but most projects don't exactly have super strict latency requirements.

I'd ask to reconsider the severity of the warning in future if possible. Maybe it doesn't need to be on by default.

Thanks for your time and for the workaround!

[kcat]

Out of curiosity, what is the output of ulimit -a on your system? Funny enough, rtkit complains I can't be given real-time priority (which I can only guess because it doesn't like the RTTIME limit my system has set), but I have no problem getting real-time priority with pthread_setschedparam.

[1bardesign]

Linux compy-mj 5.4.108-1-MANJARO #1 SMP PREEMPT Wed Mar 24 18:24:35 UTC 2021 x86_64 GNU/Linux

[kcat]

Sorry, I mean ulimit -a (editing the previous comment).

[1bardesign]

real-time non-blocking time  (microseconds, -R) unlimited
core file size              (blocks, -c) unlimited
data seg size               (kbytes, -d) unlimited
scheduling priority                 (-e) 0
file size                   (blocks, -f) unlimited
pending signals                     (-i) 62699
max locked memory           (kbytes, -l) 64
max memory size             (kbytes, -m) unlimited
open files                          (-n) 1024
pipe size                (512 bytes, -p) 8
POSIX message queues         (bytes, -q) 819200
real-time priority                  (-r) 0
stack size                  (kbytes, -s) 8192
cpu time                   (seconds, -t) unlimited
max user processes                  (-u) 62699
virtual memory              (kbytes, -v) unlimited
file locks                          (-x) unlimited

[kcat]

real-time non-blocking time (microseconds, -R) unlimited

Hmm, this is what RTKit doesn't like and will refuse giving real-time priority because of it. By default, RTKit requires the requesting thread's RTTIME hard limit to be 200,000 microseconds or less, and it will never accept unlimited even with an option (the code to parse the value fails on anything that's not a pure number). But this seems to be the default for all systems reported to me so far.

The most I could do is (irreversably) lower the RTTIME hard limit before requesting real-time priority, but as far as I understand that affects the whole process instead of just the thread. and I don't think it's OpenAL's place to change that on the app (nor do I think the app should be required to change it for OpenAL).

[1bardesign]

What do other libraries that use RTKit do in such a circumstance?

[kcat]

In SDL's case, it seems to force the limit to the necessary value. I'm not sure what other libraries use RTKit. I don't believe JACK does, PipeWire's only obvious use of RTKit seems to be in its own process, but I have a hard time wading through its codebase.

[1bardesign]

To be fair, 0.2s of real time is pretty extreme. Could have a workaround for now or raise it as an issue against RTKit; sounds like they're doing it as a safety thing though as I imagine a realtime thread going indefinitely could cause issues with the system.
Agree that it's not ideal, but it should be possible to

• try it the current way
• if that fails, try rtkit
• if they have unlimited, change to the maximum allowed limit so RTKit can work
• if that fails, just go without realtime priority

If any of these are undesirable for whatever reason, maybe they can be masked out explicitly as part of AL's configuration (both app side and user side).

For what it's worth, I'm sure it matters a lot in some cases... But for me, working on "normal" action games, the lack of realtime priority for the audio has not really been apparent. The audio still triggers when it's "meant to" as far as I can hear.

[kcat]

Could have a workaround for now or raise it as an issue against RTKit;

It seems to be intentional, so I doubt they'd change it.

sounds like they're doing it as a safety thing though as I imagine a realtime thread going indefinitely could cause issues with the system.

Yeah, I just find it a weird restriction since one of RTKit's talking points is that it runs its own real-time thread (at a priority level higher than it allows clients to take) as a watchdog for runaway real-time threads and automatically demote them. So if it manages runaway threads anyway, why require a process to have the kernel watch and autokill? It adds a bit more security sure, and it's not a bad thing to have set up, but to require it seems odd to me. Especially since it won't affect processes that don't use RTKit. If it's enough of a concern, it should be on the distro to set a safe default configuration (or the user, for distros that have the user be more hands-on).

Agree that it's not ideal, but it should be possible to

• try it the current way
• if that fails, try rtkit
• if they have unlimited, change to the maximum allowed limit so RTKit can work
• if that fails, just go without realtime priority

This is basically what it's doing now. It tries first with standard pthread_setschedparam, and if that fails, it goes with RTKit (first limiting the RTTime rlimit as needed, then trying to set real-time priority, and if that fails it tries to set high priority/low niceness). There is a config option to prevent OpenAL Soft from lowering the RTTime rlimit if it would otherwise try to, so it won't mess with the process's rlimits if that's more important than trying to get real-time priority.

The one remaining issue is that I don't know what a good priority level is for audio clients. There doesn't seem to be any standard or suggestion. I don't want it to be low enough that it can still get preempted by less important real-time tasks, but not so high that it can preempt the audio server itself. So for now pthread_setschedparam uses the minimum priority level for safety reasons, and with RTKit it opts for half the allowed maximum priority (as it has the additional protection of RTKit keeping the highest-priority reserved for itself as a watchdog, and half of max seems like a good compromise). I'd almost think trying RTKit first would be the better and safer option, but interestingly RTKit itself recommends not trying RTKit first, despite the additional protections it offers.

For what it's worth, I'm sure it matters a lot in some cases... But for me, working on "normal" action games, the lack of realtime priority for the audio has not really been apparent. The audio still triggers when it's "meant to" as far as I can hear.

At least on Linux (where RTKit is mostly used), as I understand it, its scheduler is pretty good about auto-prioritizing threads that show good behavior. If a thread regularly goes to sleep, and only wakes up periodically to do a little bit of work and goes right back to sleep, the kernel will be more keen to wake the thread up on time and not be so hasty to preempt it (in essence a thread can get automatic heightened priority for good behavior). Where you can run into problems is when the CPU is under heavy load, there's a scarce number of available cores, and the audio processing is being unfriendly. In that case, the system may need to be explicitly told that the audio thread really does need heightened priority to avoid drop-outs.

[mitinarseny]

I do not recommend using RTKit, since it depends on D-Bus, which is evil.

[Razorfang]

I get that error when using Desmume on Gentoo. Here's what I see on my terminal when I start it up:

CPU mode: Interpreter

[ALSOFT] (EE) Failed to set real-time priority for thread: Operation not permitted (1)

[ALSOFT] (EE) Failed to set real-time priority for thread: Operation not permitted (1)

[ALSOFT] (EE) Failed to set real-time priority for thread: Operation not permitted (1)

Microphone successfully inited.

DeSmuME 0.9.12 git#0 dev+ x64-JIT SSE4.2+AVX2

Using 4 threads for video filter.

OGL/SDL Renderer has finished the initialization.

OpenGL: Successfully created geometry shaders.

OpenGL: Successfully created postprocess shaders.

OpenGL: Successfully created FBOs.

OpenGL: Successfully created multisampled FBO.

OpenGL: Renderer initialized successfully (v3.2.0).

[ Driver Info -

    Version: 3.2.0 NVIDIA 470.42.01

    Vendor: NVIDIA Corporation

    Renderer: NVIDIA GeForce GTX 970/PCIe/SSE2 ]

[kcat]

This is no longer an error message with commit 834800c. It'll still warn, but warnings are off by default for release builds.

[1bardesign]

Thanks for getting this resolved 🎉