Sync 32 Projectors on 4 Machines

[Zoltán]

To be completely clear, only Resolume's internal timing comes from the audio card. Things like the BPM, Beat Snap, timeline automation, Autopilot timing, that all comes from a clock that's using the audio card. When you're using an external protocol to sync playheads, you bypass all this internal timing completely.

So if you can sync the sound cards with Wordclock, launch the clips in sync and leave the playheads alone, would the wordclock sync keep the playheads from drifting ?

Inaccurate framesync or horizontal tearing is caused by two video cards not refreshing at the same time. SMPTE or Wordclock are not going to do anything for you in this.

Yes, that's another level of the problem.

[Joris]

So if you can sync the sound cards with Wordclock, launch the clips in sync and leave the playheads alone, would the wordclock sync keep the playheads from drifting ?

I doubt it. Each computer is still running a completely separate process.

Maybe I'm not understanding the problem, but when you send the same OSC playhead value for two videos of the same length, while the clips are paused, they should be as closely synced as two clips running on SMPTE. They certainly won't drift.

[Zoltán]

So if you can sync the sound cards with Wordclock, launch the clips in sync and leave the playheads alone, would the wordclock sync keep the playheads from drifting ?

I doubt it. Each computer is still running a completely separate process.

and if the content is running on one computer only and you have multiple outputs maybe across multiple cards, will the outputs be frame synced?

Maybe I'm not understanding the problem, but when you send the same OSC playhead value for two videos of the same length, while the clips are paused, they should be as closely synced as two clips running on SMPTE. They certainly won't drift.

regarding the stuttering.. If the clips are paused then yes, they won't, but then you can't run the resolume instances as master-slave as the master will have to play the clip, which will set the slave clips to play mode too.
Without master-slave you'd have to generate the osc playhead data 0-1.0f externally and you'd need to know the exact length of each file pairs to be able to jump with osc frame by frame with the correct fps. (0.5f would not be the same frame position for different length clips, just the middle of the clips)
If the playhead could understand hh:mm:ss.ff format from a string or array via osc, then it could work like SMPTE over a network connection also supporting sync of different length clips playing at once.

Syncing via SMTPE is causing less stuttering than OSC in your experience? I would imagine that than this might be a bug in Resolume? Or is the Audio-In faster than the Ethernetport, lag-wise?

with SMPTE the video position jumps only to the current frame, but without the signal you have a paused video.
The stuttering via osc comes when you have the slave clips playing. You start the clips on sync, the master sends its playhead position over the network adding a few ms delay, then resolume interprets that data adding delay, by then the slave playhead eventually has to jump back in time.
Using an osc filter between the master and slaves, filtering the clip play mode could allow the slave clips to remain paused while keeping the synced start and playhead position data, getting rid of the stuttering.
This way you could play audio on the master with the clip in sync, you can't however play audio in an SMPTE synced clip.
And I need to mention that master slave operation in resolume is still not official.

[Zoltán]

also adding any software or hardware bridge or filter would add delay to the osc data, so if there would be an option in osc mapping to enable/disable the actual parameter data being sent or received in Resolume,
you could create your own filters in app without adding any delay to the processing.

rewriting the osc output address of the play mode to anything bogus, could also do the trick.

edit: so I found the switch in mapping mode to disable osc output for a given parameter- that's what you get from being away from a computer.-
but disabling the output for the parameter in application osc map both deck and layer focus
- layer/video/position/direction
- activelayer/video/position/direction
- activeclip/video/position/direction
keeps the /layer/video/position/direction still alive if the activelayer is not the actual layer.

[xergon]

ok, this might explain why I experienced less stuttering when I set the clip speed on the slaves manually to 99% after the clip started to play ...
so what resolume actually needs is some sort of lag-compensation for the osc playhead data. To be fair, this doesn´t sound too complicated, at least if the lag amount is not detected automatically/adaptive but set manually via the preferences in the osc tab.
Adaptive lag compensation would still be nice, think of a Wifi-Connection with packets toddling in 10-20ms late sometimes... shouldn´t be too hard to filter those playhead updates out if you usually have a steady stream of incoming playhead data in a timewise constant manner...


@Joris: what do you think of this?

[Zoltán]

I think, syncing two computers with real-time data over a variable latency network without any additional external devices thus any reference point is nearly impossible.

[Joris]

so what resolume actually needs is some sort of lag-compensation for the osc playhead data. To be fair, this doesn´t sound too complicated, at least if the lag amount is not detected automatically/adaptive but set manually via the preferences in the osc tab.

The problem with syncing multiple machines is not so much lag in the control data. Even if you bake in a lag compensation to tell each computer to set the playhead at the exact same external time, each computer will still be slightly faster or slower in getting the frame from disk, rendering the result and sending it to the output.

The real problem is getting the refresh cycles of the outputs to line up. You get nasty frame offsets when one GPU refreshes out of sync with the others. When you manage to get each GPU to request a new frame at exactly the same 60th of a second, a few millis delay in the control signal caused by network latency don't matter so much. Since the network refreshes hundreds of times more often than the monitor, it is highly unlikely that two machines are rendering a different frame at the time of a refresh.