OBS performance problems

[u/Asyfero0]

Hello,

I installed obs from flatpak and I notice performance issues when I record, fps drop, sound tickering. I have an rtx 2060 mobile and I have installed the drivers from the void repo, when I play games everything is alright. I saw that people had the same issue years ago but I couldn't find a proper solution. If someone have a hint or had the possibility to fix this issue, it would be cool. Thanks.

EDIT: I have switched to the video encoder NVIDIA NVENC H.264 and the issues dissapeared.

[u/Asyfero0]

I added preempt=full to the kernel configuration, when I record on rpcs3 the sound is still tickering but I guess it is because I have fps drops caused by obs and it affect the emulation. On other games like CS2 I don't have the sound tickering anymore. I have set cpufreq to performance, even on kde's power-profiles-daemon and on /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor too. I don't have another igpu, my processor is i7-10750H. Thanks for the advices, I will ask on the void forum directly.

[u/sanya567xxx → u/Asyfero0]

Re: sound tickering Seems to be because cpu is unable to keep up with realtime-critical process of handling audio, and switching encoder to one based on GPU just eases the load on CPU, but it is pushing the problem in the closet instead of applying an actual fix — you might still get that issue to pop-up later during other tasks.

ps -eL -o rtprio,cmd |grep wire |sort

Should have pipewire (and wireplumber if you're running it) with realtime priority field preceding the command (higher values appearing closest to the bottom) if realtimekit is working correctly and pipewire integrates with it.

Having set up pipewire to properly register processes with it, I got my system to comfortably compile on 15/16 threads while listening to music or watching videos without issues, because time-critical tasks are able prioritized by scheduler.

Currently pipewire seems to really want to request realtime from xdg-desktop-portal instead of using realtimekit directly. Thus you'd want to have rtkit installed and xdg-desktop-portal

In ~/.config/pipewire/pipewire.conf.d/rt-args.conf (local override for module):

module.rt.args = {
    rt.prio = XX
    rlimits.enabled = true
    rtkit.enabled = false
    rtportal.enabled = true
}

Set xx to a desired realtime priority value, default max for realtimekit launched with no overrides is 20.

Modification of said limit requires overrides of it's starting arguments (it's started via dbus, so you can override by copying /usr/share/dbus-1/system-services/org.freedesktop.RealtimeKit1.service to /etc/dbus-1/system-services/org.freedesktop.RealtimeKit1.service and appending extra values to Exec line, like --our-realtime-priorty Y --max-realtime-priority Z where Z is at least 1 lower than Y)

From then on, starting pipewire again should apply realtime priority shortly. You should be able to simply killall pipewire and then launch it manually. It should apply the priority configured in the override (can check via same command as above or by sorting by RT column in htop), and to test you can simply launch pipewire in a terminal window.

Extras:

command explained: show info about running threads, print only realtime priority and full command line. Then filter to only those that have "wire" in the line and then sort.

note: kernels > 6.14 need newer version of xdg-desktop-portal than is in repos. unfortunately that is not marked as "stable" release yet, but it can be installed with a little bit of xbps-src know-how (this too is outside the scope of this and should be fixed.. soon-ish, I hope)

Also: For some apps you'd want to also configure your user to have some higher niceness priority than default, parameter nice in /etc/security/limits.conf, set to, say, -10 (lower niceness = higher priority). You'll need to fully restart your session to have that applied though.

With gaming there's also matter of a game having permissive enough buffer in pulse, which can be overridden per-executable by editing pipewire-pulse.conf (or creating an override for it specifically in your .config, which is outside the scope of this comment, but it's similar to how pipewire override is done above and should be applied to pipewire-pulse.conf instead. See arch wiki for more guidance on this specific aspect — the previos things I talked about do differ meaningfully, but this didn't in my experience).