&buffer might not be keeping audio in sync

[Fred-DTV]

Hey Steve, I've tried to use &buffer as well as &sync in our last show with OBS and it didn't work. Is this still not compatible with OBS or did i do something wrong?

These were the settings I've tried on the OBS link:

• &buffer=0
• &buffer=(with values)
• &buffer=0 &sync=0
• &sync=-25

I ended up having to set render delay in OBS twice with 500ms.

OBS is 26.1. on Win10 2004

Any idea what could cause this or how to improve the sync in general?

[steveseguin]

Sadly, buffer and sync won't work with OBS on PC yet; it requires Chromium with about v80 or newer to work. OBS on PC still uses Chromium v75, so until OBS updates, it won't work.

It should work with the Electron Capture app however.

Even when it is working, it cannot fix all sync issues; it will do it's best to minimize the sync delay though.

[Fred-DTV]

what a pity, but thanks for the info!

[Fred-DTV]

Hi Steve,

fyi on our most recent production I was using your electron app for the first time. It is a great app and while we were dry testing it had almost no delay.

Unfortunately the remote guest (it was one person only) had to disconnect and connect again about 5mins before the live show and that's when the delay came back. It was the same user and the same device on both sides as before, also I didn't change any parameters. The only difference I can point out was the actual beeing live and recording through OBS.

The delay itself was actually worse then the last time when I wasn't using the electron app: I had 5x 500ms Render Delay on the OBS source in the end.

I am happy to help you out with more testing on this if you have ideas what to do.

Best, Fred

[steveseguin]

Do you know if they had an overloaded computer? I've noticed delay being introduced if the computer is at 100%; &scale=40 for example might be a way to test that theory.

Another thing that may cause it is if your own upload bandwidth gets fully saturated. I mention this as you said the difference is when going live vs not.

If you are publishing via RTMP, if all the upload bandwidth is saturated, it might make it hard for your system and their system to communicate quickly. Reducing the RTMP outbound bandwidth might be worth trying, assuming you think this is a possibility.

If you hold CTRL + Left Click on a video, you'll see stats. On the publisher side, it will also list the "quality limitation reason" stat, which will say if the quality is lowered due to CPU or Network. Might be a clue there.

You can try &codec=h264 as an option to reduce load on their system also; or try just different codecs.

Try to make sure no one is on a VPN or such. You can try different browsers's on their end. Incognito mode sometimes helps, as browser extensions can cause problems.

Hit me up maybe on discord (discord.obs.ninja) and we can do some debugging of the issue. Maybe we can replicate it? If not, it might be an issue with that particular guest/device..

-steve

[Fred-DTV]

Hey Steve,

a quick update for you, while i am still testing different scenarios: In our last show we were using the following setup with no delay at all :

• Electron App on a secondary display
• display capture OBS
• &buffer &bitrate=10000 &proaudio
• Internet connection via 5G (200down/50up/40ms)

So I think it must have been the clients Internet connection plus the situation, that we had to access their network via Wifi

I will continue trying different scenarios and keep you updated if you like, but for now I think you can close the topic