Desync when alt-tabbing on sender side.

[ItsVinnyX]

If I ALT-TAB on the sender side while in-game. the receiver will be super behind the current gameplay. Any fix for this?

Both my machines are connected via a 1 Gigabit Cat 6 cable.

[fzwoch]

I think that scenario is close to #37?

TL;DR is it seems that when the source OBS is blocking processing (loading a huge image, game capture things it seems) there will be a time of data starvation that is then caught up after the block. The result on the receiver seems to be the same - the timing gets delayed on the starvation part, but data is never discarded, re-synced after. Unless you hide/unhide the Teleport source.

[ItsVinnyX]

I think that scenario is close to #37?

TL;DR is it seems that when the source OBS is blocking processing (loading a huge image, game capture things it seems) there will be a time of data starvation that is then caught up after the block. The result on the receiver seems to be the same - the timing gets delayed on the starvation part, but data is never discarded, re-synced after. Unless you hide/unhide the Teleport source.

So to fix it, I just need to unhide/hide teleport?

[fzwoch]

InsertPerhapsMemeHere - did you try?

[ItsVinnyX]

InsertPerhapsMemeHere - did you try?

Would it be on the sender or receiver?

[ItsVinnyX]

I do not think that worked. Is there a good setup to do this?

I use WiFi on both machines. Great speeds. Both machines are connected to each other by a Cat 6 Gigabit cable. The only issue I faced with NDI was audio syncing.

[YorVeX]

That's indeed the scenario I had in #37, I specifically had on the list:

What causes the lag doesn't matter, in another scenario it was triggered by a Game Capture source that is lagged for a second when tabbing into and out of a game.

But that was fixed with Teleport 0.5.0 at least for my test scenarios, so...

• Are you sure you are on the latest version of Teleport?
• Are you using a filter to send the Teleport stream or just the base stream (as configured from the OBS "Tools" main menu)?
• Where does the desync occur? In your audio monitoring device or live audio device? In a stream sent out from OBS? In a recording?

NDI audio sync issues was exactly what brought me here (to use Teleport instead), unfortunately they don't come from NDI itself but from the OBS implmentation of it and/or how OBS works in general. That means any other OBS based solution will always suffer from similar problems. Teleport with the latest update has build a bit around the limitations of OBS in this regard and is now more stable than the NDI plugin, but it's still not 100%, at least audio monitoring still gets horrible desyncs and also the filter based solution was so bad that I stopped trying to use it entirely.

[ItsVinnyX]

That's indeed the scenario I had in #37, I specifically had on the list:

What causes the lag doesn't matter, in another scenario it was triggered by a Game Capture source that is lagged for a second when tabbing into and out of a game.

But that was fixed with Teleport 0.5.0 at least for my test scenarios, so...

• Are you sure you are on the latest version of Teleport?
• Are you using a filter to send the Teleport stream or just the base stream (as configured from the OBS "Tools" main menu)?
• Where does the desync occur? In your audio monitoring device or live audio device? In a stream sent out from OBS? In a recording?

NDI audio sync issues was exactly what brought me here (to use Teleport instead), unfortunately they don't come from NDI itself but from the OBS implmentation of it and/or how OBS works in general. That means any other OBS based solution will always suffer from similar problems. Teleport with the latest update has build a bit around the limitations of OBS in this regard and is now more stable than the NDI plugin, but it's still not 100%, at least audio monitoring still gets horrible desyncs and also the filter based solution was so bad that I stopped trying to use it entirely.

But that was fixed with Teleport 0.5.0 at least for my test scenarios, so...

Are you sure you are on the latest version of Teleport? I am pretty sure I am. Just downloaded and replaced the .dll's

Are you using a filter to send the Teleport stream or just the base stream (as configured from the OBS "Tools" main menu)?

Sender:

Receiver:

Where does the desync occur? In your audio monitoring device or live audio device? In a stream sent out from OBS? In a recording?

Occurs on the Sender side. The preview and audio are delayed.

[fzwoch]

Occurs on the Sender side. The preview and audio are delayed.

Can you elaborate on that one? I don't think Teleport should have any impact on the preview on the sender side.

If you talk about preview and monitoring - I would not trust that. If the recording on that machine is in sync then OBS audio monitoring is at fault again. I can't tell if that is intended behavior or not.

[fzwoch]

@YorVeX I think I actually found out that if you hide/unhide too quickly that the latency won't recover. I'll have to wait for a second or so before I unhide the source to make the magic resync behavior to have an effect. You see the same?

[ItsVinnyX]

Occurs on the Sender side. The preview and audio are delayed.

Can you elaborate on that one? I don't think Teleport should have any impact on the preview on the sender side.

If you talk about preview and monitoring - I would not trust that. If the recording on that machine is in sync then OBS audio monitoring is at fault again. I can't tell if that is intended behavior or not.

Okay so to be honest I noticed it more when I ALT-TABBED but in general I am noticing some delays in audio and footage. Not on the sender but the receiver it desyncs on. Sorry about that.

[fzwoch]

And again, is that in the preview or final recording on the receiver?

[ItsVinnyX]

And again, is that in the preview or final recording on the receiver?

It seems like it’s the preview. I use it to stream. I haven’t seen what it looks like on stream. But via audio monitor and visuals it’s definitely out of sync.

[YorVeX]

@YorVeX I think I actually found out that if you hide/unhide too quickly that the latency won't recover. I'll have to wait for a second or so before I unhide the source to make the magic resync behavior to have an effect. You see the same?

@fzwoch You're talking about hiding/unhiding the Teleport source on the receiver? Then yes, this matches with my observations. You can actually hear it: if you hide/unhide too fast, then the audio will never stop. You need to hide so long (for me a little more than a second I'd say) until you no longer hear the audio, then unhide and audio is in sync again.

@ItsVinnyX you seem to go by the preview. This actually still does break for me even with Teleport 0.5.0, since audio monitoring breaks because of lags and on the receiver side audio monitoring is the only way to hear the sound from the preview. Maybe that's because it has it's own set of problems, either way I am 90% sure there is nothing Teleport could do about this, that's an OBS thing.

I just accepted that it is that way, in the end what's more important is that stream and recording are OK, and since 0.5.0 for me they are - in all my test scenarios where both NDI and Teleport versions prior to 0.5.0 would break.

But as I said above, hide the Teleport source on the receiver long enough and show it again and it's fixed. Of course that's not ideal, because it means an interruption of the stream for your viewers, so I'd rather just try to get a setup that is so stable that I don't have to fear A/V desync and then I either don't need the preview (if checking for A/V desyncs was the main reason for checking the preview in the first place) or if I want to check something else from the preview maybe in this case I could just live with the desync.

If you really really need to regularly check the preview with working A/V sync and have both the CPU power and bandwidth you could have the receiver again output a Teleport "Preview" stream and on the sender prepare a separate "OBS Sync-Check" instance, which tunes into that "Preview" feed and outputs the audio only to your monitoring device. This way you can always fire this up when you want to do a preview check and unlike the monitoring audio from the receiver itself it will have proper A/V sync. I know it's a bit complicated but it does work at least for me.

[fzwoch]

@fzwoch You're talking about hiding/unhiding the Teleport source on the receiver? Then yes, this matches with my observations. You can actually hear it: if you hide/unhide too fast, then the audio will never stop. You need to hide so long (for me a little more than a second I'd say) until you no longer hear the audio, then unhide and audio is in sync again.

Oh God.. my sanity..

But if the recording is fine AV sync wise I think it is the same as #37. I don't really know what to do when the same data can be correct and incorrect at the same time. It may be that the audio meters reflect the potential audio monitoring path which may break up sync in favor of monitoring instead of delaying the audio for syncing it to the video.

Also: https://github.com/obsproject/obs-studio/pull/6769

This allows the lowest possible consistent latency for audio buffering, which is useful for the Decklink and NDI outputs which cannot rely on audio timestamps for synchronization

[fzwoch]

Closing, as it seems to be the the same issue as the other.