Skip to content

Merge module-rt and module-rtkit into a single module-rt

This should make using PipeWire for pro audio a bit more convenient as those users will likely already have realtime privileges set up. As suggested in RTKit's documentation, this will use regular realtime scheduling through sched_setscheduler()/pthread_setschedparam() if that's available, only falling back to rtkit if it is not. The implementation should also work on FreeBSD, but to my knowledge there's currently no way for non-root users to use realtime scheduling on FreeBSD so that will be of limited use. And this also fixes a small memory leak because impl->props was never freed in the original module-rtkit.

A couple of questions and things that need to be solved remain:

  1. In module-rtkit, impl_acquire_rt would ignore the priority argument passed to the function and instead always use the priority set in the configuration file. module-rt did the opposite. What is the correct approach?
  2. Since there's now a single module-rt and module-rtkit no longer exists, this will break realtime scheduling in existing non-default configurations that used module-rtkit. Does PipeWire already have some way to (temporarily) provide aliases for modules to prevent this?
  3. Another related thing that keeps coming up in IRC and several Discord servers I frequent is RLIMIT_RTTIME. Both PipeWire and RTKit (if it's in use) set this right now, but no other software does. While there should never be a good reason for programs to exceed the 200 millisecond or 2 second deadlines set by RTKit and PipeWire, in practice it can happen. When something like that happens, the expected behavior would be a flood of xruns, after which the user can either change some things so it no longer happens (when using very DSP load intensive processing chains in a DAW, for instance), or they can ignore it if it's a one off thing. With PipeWire however, this will cause their DAW to be SIGKILL'd, and even very technically inclined users will likely have no indication as to why that happened. There's no way to override the limit imposed by RTKit from PipeWire's side, but I would like to propose not setting RLIMIT_RTTIME/setting the module-rt's defaults to -1 when using regular realtime scheduling. This will lead to fewer surprises, and in my opinion a bunch of xruns is always better than a program getting SIGKILL'd and possibly losing work.

Merge request reports