Pipewire - audio underrunning heavily at low buffer sizes when using external interface

[rexendevar]

Hello, this is a problem that I've had ever since switching to the new scheduler, and I've only just now decided it probably is its own issue and not the same one that has already been submitted. Basically I want to use S76-sched to enable realtime audio recording within reaper. To this end I set sample rate to 48k in Pipewire and buffer size to 128, thereby creating a total round-trip latency as reported by reaper of 7.3 ms. This worked perfectly well on the old scheduler, but absolutely does not on the new one, where it causes unusable underrunning that is not counted within either Reaper or Catia.

https://www.reddit.com/r/linuxaudio/comments/13ettdi/system76scheduler_20_getting_horrible (reddit post with extensive troubleshooting)

The scheduler seemed to be capable of setting the niceness values, but they didn't seem to do anything with regards to making the system keep up with the audio processing. I don't know whether this was an issue within Pipewire or the kernel or what, but I suspect it's the scheduler; that said I think I did run a general update command that could have updated all three at once. This does not involve easyeffects, only reaper and pipewire themselves, as i had a track record monitored and could hear the direct output being trash. As far as I can tell the underrunning is primarily on the output, which does track with past experiences that say very low buffer sizes with a Scarlett actually make monitoring worse.

Sorry for the scattered thoughts on this one, let me know if there's any crucial information missing.

[cmm]

A couple of days ago I got annoyed by skipping audio (and other desktop jank) under load just enough to bother doing some proper (FSVO) research and experimentation, and wrote down my findings here: https://cmm.github.io/soapbox/the-year-of-linux-on-the-desktop.html

The specific configuration changes there are for NixOS (life's too short to debug other people's crusty setups on "traditional" distros, sorry), but should be easily translatable if you know what you are doing.

The test subject was a 11-year old Lenovo x220, and the test itself consisted of playing music while doing a clean "cargo build" of system76-scheduler + some web browsing.

One interesting (and not terribly surprising) conclusion of that research if that you don't need most of the advanced features of system76-scheduler at all, at least when it comes to playing music. Specifically, the new Pipewire-client-boosting logic seems to be completely superfluous; all you need is for Pipewire to be able to assign itself the scheduling classes and priorities it wants -- the kernel is smart enough to make sure clients keep up. preempt=full and threadirqs are also important.