Tell Linux to schedule osu! as real-time using RealtimeKit

[Thesola10]

RealtimeKit (or rtkit) is a service found on Linux systems which allows unprivileged programs to ask for real-time scheduling of their threads. In order to do this, osu! would have to perform a D-Bus call to the RealtimeKit service with the thread ID that needs to be upgraded to real-time.

This is worth doing on desktop systems as it would help keep latency low under system load, with an easy fallback route: No D-Bus access or no RealtimeKit service = silently give up and use the scheduling we're given.

To avoid clobbering the real-time scheduler, this feature would only be activated by using the "Multithreaded" backend setting.

[smallketchup82]

Hi there, I did some digging on this as I've previously worked on osu!'s audio backend, and I was personally interested in this idea. From what I've found, it seems like osu! does already request real-time privileges, although to an extent.

Pipewire and Pulseaudio both automatically use rtkit to elevate their threads to realtime. However, osu!'s audio library, BASS, only outputs audio on linux via ALSA.

Therefore to ensure realtime audio is available, one must ensure they have an ALSA compatibility layer installed (e.g. pipewire-alsa, pulseaudio-alsa), and that they're outputting to either one (pipewire would be named Pipewire Audio Server)

While we can add functionality for osu! to request realtime privileges, this would only be useful if the user is directly outputting to ALSA (via selecting a device other then pipewire/pulse in the audio settings). And to be frank I feel like this is a bit of a scope reach, since ideally BASS should be doing that for us.

I believe it would be better to add the pipewire/pulse compatibility layers as suggested packages on the distro packages, and prioritize using them by default if installed, rather than manually calling rtkit. Let me know what you think of this.

[sineplusx]

And to be frank I feel like this is a bit of a scope reach, since ideally BASS should be doing that for us.

I think it already is. I am currently running osu! on raw ALSA, low latency and having no issues. From the BASS documentation:

On Linux, BASS will attempt to set the device buffer-feeding thread to real-time priority (as on other platforms) to reduce the chances of it getting starved of CPU, but if that is not possible (eg. the user account lacks permission) then it may be necessary to increase the buffer length to avoid breaks in the output when the CPU is busy.

If I check ps -Lp $(pidof osu!) -o pid,tid,ni,rtprio,cls,comm it shows me at least one audio thread running in round-robin scheduler:

    PID     TID  NI RTPRIO CLS COMMAND
  28558   28558   0      -  TS osu
  28558   28559   0      -  TS .NET SynchManag
  28558   28560   0      -  TS .NET EventPipe
  28558   28561   0      -  TS .NET DebugPipe
  28558   28562   0      -  TS .NET Debugger
  28558   28563   0      -  TS Satori GC Trimm
  28558   28564   0      -  TS .NET Finalizer
  28558   28566   0      -  TS .NET Timer
  28558   28568   0      -  TS .NET TP Gate
  28558   28570   0      -  TS .NET Sockets
  28558   28571   0      -  TS LegacyTcpIpcPro
  28558   28573   0      -  TS osu
  28558   28574   0      -  TS osu
  28558   28578  19      0   B osu:disk$0
  28558   28579  19      0   B osu:disk$0
  28558   28580   0      -  TS Audio (GameThre
  28558   28581   0      -  TS Update (GameThr
  28558   28582   0      -  TS Draw (GameThrea
  28558   28583   0      -  TS HID System Even
  28558   28584   0      -  TS HID Manager
  28558   28594   -      2  RR Audio (GameThre
  28558   28595   0      -  TS Audio (GameThre
  28558   28596   0      -  TS Audio (GameThre
  28558   28597   0      -  TS Audio (GameThre
  28558   28598   0      -  TS Audio (GameThre
  28558   28599   0      -  TS osu
  28558   28618   0      -  TS HID Reader
  28558   28619   0      -  TS HID Writer
  28558   28620   0      -  TS OpenTabletDrive
  28558   28621   0      -  TS HID Reader
  28558   28622   0      -  TS HID Writer
  28558   28623   0      -  TS OpenTabletDrive
  28558   28624   0      -  TS osu
  28558   28625   0      -  TS APIAccess
  28558   28632   0      -  TS ThreadedTaskSch
  28558   28634   0      -  TS ThreadedTaskSch
  28558   28635   0      -  TS ThreadedTaskSch
  28558   28636   0      -  TS ThreadedTaskSch
  28558   28637   0      -  TS ThreadedTaskSch
  28558   28638   0      -  TS ThreadedTaskSch
  28558   28641   0      -  TS ThreadedTaskSch
  28558   28642   0      -  TS ThreadedTaskSch
  28558   28643   0      -  TS ThreadedTaskSch
  28558   28644   0      -  TS ThreadedTaskSch
  28558   28645   0      -  TS ThreadedTaskSch
  28558   28646   0      -  TS ThreadedTaskSch
  28558   28647   0      -  TS ThreadedTaskSch
  28558   28648   0      -  TS ThreadedTaskSch
  28558   28662   0      -  TS .NET TP Worker
  28558   28663   0      -  TS Discord IPC Thr
  28558   28675   0      -  TS Audio (GameThre
  28558   28913   0      -  TS .NET TP Worker
  28558   28926   0      -  TS Audio (GameThre
  28558   28963   0      -  TS .NET TP Worker
  28558   29068   0      -  TS .NET TP Worker

Dunno if this is the correct interpretation though.