stormy Posted October 25, 2017 Share Posted October 25, 2017 I recently expanded my IO with a Focusrite Clarett Octopre, which is connected to my RME Fireface 802 via ADAT and clocked via BNC cable. I use a bit of outboard gear, using the I/O plugin. When I was using the RME only, the "ping" would always report 0 samples. However, when I send or receive audio through the Focusrite, the "ping" reports a delay that varies from +4 to +32. The problem is that I'm finding that the value can change later on the same session! Is this expected? Do I need to re-ping all I/O plugins before doing the final bounce in order to avoid problems? Any ideas what can be causing the change in values? BTW I've just noted this in the Logic Pro manual: "Note: Bypassing any latency-inducing plug-ins on the track will provide you with the most accurate reading." I will double check this, it might have something to do with it. Quote Link to comment Share on other sites More sharing options...
rAC Posted October 26, 2017 Share Posted October 26, 2017 Also if you are connected by ADAT you don’t need (and it can be detrimental) to have a Word clock connection separately. The ADAT will supply the clocking. Quote Link to comment Share on other sites More sharing options...
stormy Posted October 26, 2017 Author Share Posted October 26, 2017 I will try that, but I was under the impression that clocking via BNC is more solid. The Focusrite interface has a button to select the source of clocking. I could also try clocking the RME from the Focusrite and see what happens. Upon testing today, I got the same values on an empty project and on a busy one. I hope they stick! Quote Link to comment Share on other sites More sharing options...
stormy Posted November 1, 2017 Author Share Posted November 1, 2017 Using the Focusrite as the master clock via ADAT doesn't improve things. Ping values can drift when opening the same session the following day Quote Link to comment Share on other sites More sharing options...
stardustmedia Posted November 1, 2017 Share Posted November 1, 2017 0ms is wrong. That's impossible. Zero latency doing DA, then back AD will always have latency. Does the latency change when you just ping consecutively without doing something else? I found out, that the latency may change, when adding/removing plugins, busses, routings, etc The outboard gear used is what? I once was confused about a changing latency, when I pinged a modulated delay/chorus/ etc. where the FX was set to 100% wet But I've never encountered that issue when just pinging a couple of times in a row an all analog gear signal flow, that cannot introduce a delay at all. For instance all analog EQ into all analog compressor. Quote Link to comment Share on other sites More sharing options...
stormy Posted November 1, 2017 Author Share Posted November 1, 2017 0ms is wrong. That's impossible. Zero latency doing DA, then back AD will always have latency. As far as I know, "0 samples" in the Ping value simply means that the RME is correctly reporting latency to Logic, and the DA AD is accounted for and corrected "under the hood". In fact, I can record the external processor and get it to (almost) null against the source, so I believe the I/O plugin is behaving correctly. This is also in line with the external interface having latency, since there would be no way for the RME to calculate that. It's the changing value that puzzles me. I'm using mostly EQ and compression, and always bypass the units when doing the ping test. Does the latency change when you just ping consecutively without doing something else? I found out, that the latency may change, when adding/removing plugins, busses, routings, etc Maybe that's got something to do with it. My impression is that simply opening a new session the next day would change the ping values. Quote Link to comment Share on other sites More sharing options...
Solution stormy Posted November 4, 2017 Author Solution Share Posted November 4, 2017 I've run and recorded an impulse through the I/O, and I can confirm this is NOT a problem with Logic Pro. In fact, I've verified that the I/O plugin does exactly what it's supposed to do, no matter what the reported value is. Tracks run through the I/O and recorded via buss on another track are always sample aligned. I've also verified that when the RME reports zero samples delay, it is indeed correct. All the compensation is happening behind the scenes. Quote Link to comment Share on other sites More sharing options...
Eric Cardenas Posted November 4, 2017 Share Posted November 4, 2017 Thanks for reporting back Stormy. Quote Link to comment Share on other sites More sharing options...
jeffloven Posted April 3, 2018 Share Posted April 3, 2018 I find this fascinating! Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.