Have you attempted to send a 2-pop to the renderer and to the output bus at the same time? Im getting a 3 frame delay on the renderer. This is not fixed with video sync offset It makes it worse.
I've confirmed the same with another persons system.
*Ive recorded the pops with my sony d50 and can confirm the delay is about 2.75 frames
its actually a 2.75 frame email@example.com Video sync offset wont fix it. If I put 11 qf delay on video off sync catchin sync now reports 5 frames of delay between the pop and the picture.
Might I ask what you are trying to achieve with this test?
The Renderer is known to have a delay inherent in the signal path which can be compensated for by the Video Sync Offset but you appear to be sending to an output bus also which would bypass the Renderers delay and therefore be the source that Pro Tools was trying to compensate for with the Video Sync Offset.
I guess I'm trying to ascertain why you'd be sending to the renderer and also to a direct output.
The renderer is out of sync by 2.75 frames. If I try to account for this with video sync offset by adding 11 qf of delay I end up with the audio being out of sync by 5 frames. My reason for doing this is I am trying to figure out why there is a noticeable delay on anything traveling through the local renderer.
Protools video sync offset doesnt care about what bus is what. You just tell it how many qf to offset and it does it. It I adjust it for the local renderer it should make the local renderer and everything going to it in sync. Obviously anything not going to the local renderer will be out of sync. The issue is adjust the video sync offset increases the latency in the local renderer.
I've confirmed this issue on someone elses system.
* it doenst increase the latency in the local renderer but makes the entire system even more out of sync.
12.8.2 is my protools version.
Right, i'm just trying to understand why you are sending to the renderer and the output bus at the same time?
Does the issue change at different frame rates i.e. if you set 11qf at 30 fps does it behave differently than at 23.976 for example?
Could you share your test session for someone to take a look at?
I cant change the frame rate as its tied to the video. If you give me a email I can send a ptx file. But the issue is within protools/the renderer not doing the expected thing with the video sync offset.
email it to firstname.lastname@example.org
Hi Jeff. Is this an HDX system? If so please make sure to use the multi-mono DSP versions of the Renderer Send and Return instead of the Native versions as this can affect the latency of the renderer.
yes this is hdx2. I am using the dsp versions of the plug ins. Thanks.
I dont think the returns are reporting the correct latency of the renderer or protools isnt doing the correct delay compensation. Im seeing 6146 samples at 48khz.
I believe that is 128ms?
3 frames is around 120ms.
So maybe the returns ARE reporting the correct latency but protools isnt doing the delay compensation?
I am running 12.8.2
do my pops test. Send pops direct to the speakers and a set of pops thru the renderer. If delay is being compensated they will arrive at the same time.
Delay compensation and Video Sync are two different processes.
1/ Delay compensation is not automatic with the Production Suite which is why it is advised not to do Mastering with the tools but rather initial track lay and final qc of Mastered content.
2/ Video Sync offset should be functioning just fine.
How can you do initial track lay if you are 3 frames out of sync?
video sync offset isnt compensating for the delay of the renderer.
If you are using a quicktime locally i.e. without video hardware. does it look in sync?
If not is it by 3 frames?
Video sync offset has no effect on internal video playback so just trying to track down where this issue is occurring