Bug Report OS X - Mic Audio Loses Sync When Lots Of Action On Screen Then Sync Returns When Action Calms Down

[kaiservongrauer]

While streaming Battlefield V gameplay from my Xbox One X, microphone audio falls out of sync when there's a lot of action happening on the screen; when the action dies down, microphone audio sync returns. The issue doesn't happen immediately after starting the stream, typically happens after an hour or so. The issue seems to go away when I reboot and restart the stream.

I've been running this configuration on my 2018 MBP for the past year and a half and the problem has only been happening intermittently for the past six weeks.

OBS 24.0.6; MacOS 10.15.4. Log file attached; let me know if you need additional information.

 

[Narcogen]

I don't see any audio issues related to your microphone in the log, but audio issues are generally a symptom of CPU overload and you are using the CPU encoder.

18:13:43.892: adding 69 milliseconds of audio buffering, total audio buffering is now 69 milliseconds (source: Alerts > OBS, StreamDeck, iTunes)
18:16:33.813: adding 23 milliseconds of audio buffering, total audio buffering is now 92 milliseconds (source: (null))
18:16:59.821: adding 23 milliseconds of audio buffering, total audio buffering is now 116 milliseconds (source: Alerts > OBS, StreamDeck, iTunes)
18:31:29.678: adding 23 milliseconds of audio buffering, total audio buffering is now 139 milliseconds (source: (null))
20:52:53.187: adding 23 milliseconds of audio buffering, total audio buffering is now 162 milliseconds (source: (null))
20:52:53.303: adding 23 milliseconds of audio buffering, total audio buffering is now 185 milliseconds (source: (null))
20:52:53.653: adding 23 milliseconds of audio buffering, total audio buffering is now 208 milliseconds (source: stinger_test)
20:52:54.396: adding 23 milliseconds of audio buffering, total audio buffering is now 232 milliseconds (source: stinger_test)
20:52:54.626: adding 23 milliseconds of audio buffering, total audio buffering is now 255 milliseconds (source: stinger_test)

 

[kaiservongrauer]

Narcogen, thanks for your reply.

I did a bit of research and found new version of the Focusrite Control software for my Clarett, went ahead and updated it.

I also went through the log and saw the same thing that you pointed out above. A few days ago I'd been playing around with alternate methods of triggering stinger transitions through my StreamDeck. I'd added a source for the stinger movie file to my stream scene, did some experimentation, turned off the visibility of the stinger_test source, and promptly forgotten about it. I deleted it. Perhaps even though it was hidden it was still causing issues?

For as long as I've been streaming, I've been using the x264 encoder because of the three encoder options that I can see (Apple VT H264 Hardware Encoder, Apple VT H264 Software Encoder, x264) x264 is the only option that allows me to set the rate control to CBR, and I'm mainly doing that to keep Twitch happy, as it's the only service I stream to.

If you check the bottom of the log, it seems like my system can handle streaming to x264 with my current settings pretty well. Would you recommend using a different encoder (H264 Hardware or H264 Software) to head off this audio issue in the future?

Thanks again!

 

[Narcogen]

Some users have trouble with the Apple encoders as well. I have never regularly used them myself, sticking with x264 in MacOS and NVENC on Windows.

I imagine there should be a CBR equivalent rate control with the Apple VT Hardware Encoder. It might just be called something else.