So with every other game I have tested in my GPU passthrough situation, none have interfered with the host when it’s recording/streaming using OBS… until now.
Crash Bandicoot N. Sane Trilogy during load screens manages to use 90% CPU usage on the guest, and it finally caused my host’s Pulseaudio capture at 96000hz to start dropping samples.
Tried hugepages in the host and core affinity in the guest to resolve it but it’s still there during loads…
I wonder if this is at all common, so I want to conduct an experiment that I want people who own this game and use it in passthrough to try out:
-
Play a 1Khz tone into the Line In of your sound card, which the host should be using.
-
Set the sound card default formats to this in
/etc/pulse/daemon.conf:default-sample-format = s32le default-sample-rate = 96000 -
Launch OBS and just record that input with the default settings, cause this is not testing video encoding CPU usage.
-
Make sure the guest is running at the same time, then run a Crash NST loading screen.
-
Play back the recording or import it into Audacity to see if it dropped samples.
I’d be interested to know if using UMA on Threadripper might be able to solve this problem, and if it affects any other high core count CPUs with mitigation steps. A low level examination of the resource use would be helpful to find out why Pulseaudio drops samples ONLY DURING CAPTURE, because it can playback flawlessly when Crash NST is loading a level in the guest VM.
I’m suspecting it might not be solely related to CPU because loading a Crash NST level also taxes the memory quite hard.
Either that, or it’s a bug in OBS Git. If this is not happening with the default FFmpeg AAC encoder, might be a quirk with libfdk-aac. But I have used that fine for the last 6 months.
I have noticed encoder overloads due to slow disk I/O, but even when it’s reading a level from memory, the issues happen, so I don’t think it’s disk I/O.