Decklink Monitor out of sync on OBS 29.1.0

Andre Caleffi

New Member
I use OBS Studio to receive the SRT signal via internet and send this signal via SRT through an SDI port through Decklink Mini Monitor 4k.
When I open OBS the signal comes out perfectly, everything is smooth and synchronized. But after a while it loses sync.
The SRT signal is not entering all the time, it only opens when the transmission starts, I don't know if that changes anything.
I'm using Ubuntu Linux.
In OBS there is no loss of rendering packets or anything. In CPU usage monitors and everything else in linux everything is perfect.

The lack of synchronization happens only on the Decklink output. When I make a simultaneous transmission to youtube for example through the same OBS on youtube it is correct and not on the output of Decklink.
 

AaronD

Active Member
I use OBS Studio to receive the SRT signal via internet and send this signal via SRT through an SDI port through Decklink Mini Monitor 4k.
When I open OBS the signal comes out perfectly, everything is smooth and synchronized. But after a while it loses sync.

...

The lack of synchronization happens only on the Decklink output. When I make a simultaneous transmission to youtube for example through the same OBS on youtube it is correct and not on the output of Decklink.
You didn't actually say so, which muddies the water a bit, but I suspect you've found the classic problem of OBS's audio Monitor drifting out of sync with everything else. The problem is possible with *any* use of OBS's Monitor, because it was written badly a long time ago and never fixed.

The problem has to do with sampled (discrete time) audio and multiple independent clocks. OBS has its own clock, that comes from the operating system, which can in turn have some variation on where it actually comes from. Meanwhile, a peripheral card may or may not have its own independent clock. Maybe its designers didn't trust the system clock and so they put one on that they do trust, or whatever.

Having two independent clocks is similar to having tape measures that are slightly different sizes. They start out close enough, but if you keep going, they're worthless. The same nominal spec ends up vastly different depending on which measure you use. Same with clocks. Older pro rigs have an explicit clock signal that is wired to all of its gear; new ones can extract it from other signals, but it's still important to make sure that everything is using *exactly* the same clock.

If your entire system were in fact using the same clock, then OBS would not have a problem. But because it's not, and that part of OBS was written badly, it does.

Instead of resampling, or even just dropping/stuffing samples to keep it in time, it simply expands the buffer, ad infinitum. That's one of the easiest things to do as a software dev, and a non-audio guy probably won't even see a problem with it. He'll just assume (wrongly) that it's just some isolated communication hiccups and not a constant fundamental problem like clock-drift is. One of the (present) developers even defended the buffer-expansion to me as, "how else would you keep sync with the card," but completely missed the bigger picture of getting uselessly out of sync with everything else.



There are two ways to work around it:
  1. Periodically disrupt the Monitor, so that the buffer resets. There are lots of ways to do this, including:
    • Reconfiguring the Monitor device, in Settings -> Audio -> Advanced -> Monitoring Device. Set it to anything else, Apply, set it back, OK.
    • Reconfiguring the Output/Monitor option in the Advanced Audio Properties for each source. Set it to "Monitor off" and then back to "Monitor and Output".
    • Reconfiguring the source itself. This affects the stream and recording too (*), so be careful with it.
    • Removing and re-adding the source itself. This also affects the stream and recording (*).
    • Blinking the mute button. Again, this also affects the stream and recording (*), but it can be scripted fast enough to be hard to notice.
  2. Send the Monitor to a virtual device that uses the same clock as OBS (probably will, because it's driven by the same OS), and then "bounce" it from there to the actual output device. This gives the virtual device its own chance to do it right, instead of OBS. This could be:
    • A DAW, in which case you might consider doing ALL of your audio processing in there. Then OBS only gets a finished soundtrack to stream or record from itself, and nothing else. I like Ardour (sudo apt install ardour) and JACK, but there are others too. On Windows, Voicemeeter is popular.
    • A custom configuration of PulseAudio and/or ALSA, to create an intermediate virtual device that OBS connects to, and then from there to where you actually want it. I've played with that a bit, but forgotten pretty much all of it. But now that you know some search terms, maybe Google can help.
    • A custom configuration of PipeWire if you have that. The Linux world is in the middle of switching from PA and JACK, to PW by itself, and Ubuntu is one of the slower adopters. But I think the latest non-LTS release or two does have it now? LTS needs to wait for 24.04, as the latest of those, 22.04, seems to have just missed it.

(*) The last three points of #1 could be improved by having a separate copy of each source: one goes to the stream and recording ("Monitor Off" in the Advanced Audio Properties), and one goes to the Monitor ("Monitor only (mute output)"). Then you can mess with the Monitor copy while not affecting the Output.
 
Last edited:
Top