Sync behavior within groups

[Nick Kourtides]

Hello list,

In the v3, in order to guarantee sync between, say audio stems and timecode, we'd put them in the same "fire all children at once" group. Is this still a requirement in v4?

I ask because a...ahem...rogue technician on one of my tours running v4 seems to have taken it upon themselves to rewrite a show that had been authored in v3 with stems, MTC, LTC, and video cues within the same groups for this reason. They "cleaned up" the cueing structure to put audio, timecode, and media cues in their own groups, and then encompassed all within a single green group. I have not seen the show run yet personally, but in v3 that cueing structure would not remain in sync.

Any ideas?
Nick

[Christopher Ashworth]

Hi Nick, 

Without seeing the workspace I can't say for sure,  but based on this description I believe that would be synced in both v3 and v4.

The requirement is that the cues be triggered to start at the same time (not after any waiting period).  Any cues that ought to start "instantly" and together will be guaranteed to stay in sync.

-C

(mobile)

--

[Nick Kourtides]

Thanks Chris for the fast response!

Your description of:

The requirement is that the cues be triggered to start at the same time (not after any waiting period).  Any cues that ought to start "instantly" and together will be guaranteed to stay in sync.

 

has not been my experience in v3. Typically when other departments are chasing timecode we'll have to start code a fraction early as pre-roll and prewait the audio stems by the equivalent amount. For example, start LTC at 00:59:59:15 at 30fps and prewait the audio stems all by 0.50 second. If the audio stems AND the LTC cues are within the same fire-all-at-once group they would remain in sync. If the LTC cue was moved out of that group, even to another green group that still encompassed the stems group, they would drift. I've seen this with both Watchout and D3s chasing timecode. But if all is within the exact same group, even after 10 or 11 minutes we're still in sync, despite any pre-waits.


 

[Chris Ashworth]

Hi Nick!

Hm, I’m not sure — this doesn’t describe how the code is designed or how it works to the best of my knowledge.

Reviewing the code again this morning and conferring with Sean, neither v3 nor v4 will allow drift if the LTC and Audio are going to the same audio device. When it comes to delivering the actual samples, the underlying engine is agnostic about the cueing structure...

-C

[Nigel Hogg]

I experienced drift of up to 1 second between audio stems and timecode in a show last year even with the cues in a fire all group. When I replaced the 5200 rpm hard drive with an SSD the problem went away, so I assume it was related to the speed at which the audio was read from the drive.
Nigel

[Chris Ashworth]

Hi Nigel,

Video and audio will not be synced unless the video has an audio track, and the audio is all assigned to the same logical device — so depending on the system design this can be expected.

The speed of the storage media will affect: 

 - if audio drops out due to buffer under-runs

 - “pseudo” sync for cues assigned to different logical audio devices; if all the audio is ready for all the devices faster, then they will tend to be more in sync than with a slower drive (but that sync is not locked in the way it is for audio to the same device)

The speed of the storage media does NOT affect drift; the audio engine is specifically designed to not drift, no matter how slow the drive is.

-C

[Chris Ashworth]

One thing I’d like to try to clarify in this thread is the distinction between "synchronizing when cues start delivering audio", and “drifting synchronization of separate audio streams over time”; they’re different things and might be causing confusion if we’re not talking about the same one but think we are….

-C

[Nigel Hogg]

Hi Chris,

The sync problem I had was between LTC, generated by a timecode cue and audio cues in the same fire all group. When running my main mac mini with an SSD, and the backup with a standard hard drive, I noticed that the backup was drifting, but the main (with SSD) was not. I assumed that the SSD was the 'cure' for drifting - this may have just been a coincidence. The two systems were identical in every other respect.
Whatever the cause/cure, I now no longer drift!

Nigel

[Chris Ashworth]

Hi Nigel,

Not to beat a dead horse, but are you sure you mean “drifting”?  

The best guess I have based on what you’ve described is that you experienced a difference in when different cues started, but did not experience drift between those cues.  

This guess is based on:

• I would need to dig in further, but it seems possible at first glance when I review the code that LTC cues and Audio Cues may not have a guarantee starting sync (in v3 or in v4)
• But also after review, we’re pretty confident that the audio output of LTC and Audio cues can not drift, and especially can not drift due to the speed of the storage media.

-C

[Nigel Hogg]

Hi Chris

Thanks for clarifying the difference. As I recall the 'offset' of the audio and timecode stayed constant throughout, which would tend to indicate that the audio started slightly later, but then stayed at the same offset relative to the timecode. It was only a small amount, but enough to upset the lighting designer!

Nigel

[Chris Ashworth]

<nod> Cool — that would line up with the speed of the storage media making a difference.

I’ll put it on the list to double check and confirm that the start of LTC audio output is synchronized with the start of other audio output when the cues are programmed to begin simultaneously and assigned to the same audio device. 

From inspecting the code I believe that to be true, which would mean a lack of sync would be from something not satisfying those conditions e.g. different devices or cue programming.  But I’ll put it on the list to test and confirm!

And speaking back to the very original question of the thread: however it behaves, it hasn’t changed in any way between v3 and v4.

Cheers,

C

[Charles Coes Lists]

I have experienced a later (and variable) start time for MTC (generating LTC in a Rosendahl box) compared to audio (it ran a 50 minute tightly cued show after that with no drifting apart over time) way back in V3, it wasn't something we could solve, so we wound up printing LTC to audio files and running that....  I'll try them in V4...

Charles Coes

cco...@gmail.com
https://www.soundmindsdesign.com/charles-resume
"Whether we like it or not we are amphibians, living simultaneously in the world of experience and the world of notions, in the world of direct apprehension of Nature, God and ourselves, and the word of abstract verbalized knowledge" - Aldous Huxley.

-- 
Contact support anytime: sup...@figure53.com
Follow Figure 53 on Twitter: http://twitter.com/Figure53
--- 
You received this message because you are subscribed to the Google Groups "QLab" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qlab+uns...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qlab/etPan.597a43ab.45496164.b33b%40chris-mac-pro.local.
For more options, visit https://groups.google.com/d/optout.

[Andy Lang]

On Thu, Jul 27, 2017 at 6:26 PM, Charles Coes Lists <ccoes...@gmail.com> wrote:

I have experienced a later (and variable) start time for MTC (generating LTC in a Rosendahl box) compared to audio (it ran a 50 minute tightly cued show after that with no drifting apart over time) way back in V3, it wasn't something we could solve, so we wound up printing LTC to audio files and running that....  I'll try them in V4...

None of what we’ve discussed applies to MTC. We’re strictly talking LTC here. MTC should always be your absolute last choice for synchronization.

MTC has no way to sync to anything else, since MIDI devices don’t have word clock, and in fact, as simple FIFO serial devices at their heart, don’t have any guarantee of timeliness of any sort. That’s one of a bunch of reasons why I strongly discourage using MTC. Ever.

The others include the significantly longer lock time due to quarter-frame messages, and the fact that I can name exactly two brands of MIDI device that don’t corrupt MTC (or other of the more data heavy message types like SysEx and MSC), those being ESI and iConnectivity. Every other brand, major and minor, that I’ve tried has issues with an out of date design with too small of a buffer eventually causing corruption to MTC.

Then, with the Rosendahl, you’re adding another layer of conversion that’s further delayed by the need for 4-8 complete MSC quarter-frame messages to come in to be able to output the first frame of LTC, and all bets are off.

If you need to use timecode, use LTC from a timecode cue, or striped audio, whenever possible. If you do the latter, make SURE the striped audio is at the same sample rate as the output device; resampling LTC isn’t exactly the most reliable idea :o)

-Andy

—
Andy Lang
@SoundGuyAndy
sup...@figure53.com

​

[Christopher Ashworth]

MTC is definitely not synced to anything; it just runs off the computer clock.

(mobile)