|
Avid Pro Audio CommunityHow to Join & Post • Community Terms of Use • Help Us Help YouKnowledge Base Search • Community Search • Learn & Support |
#1
|
|||
|
|||
Different latencies when printing
Hi friends,
I use Pro Tools 2023.9 (1024 buffer) on Monterey with the Cranborne 500R8 which contains some 500 series modules (pre, eq, comp). I have a project with some audio tracks that I pass (one by one) through the same hardware chain, printing them all onto new “processed” tracks. Every time I print the track, I check how much it is delayed compared to the original and align it by hand. The problem is that, every time, I have different latencies! For example, I have to anticipate a track by 160 samples, another by 120, another by 600! Yet they go through the exact same chain (I put the hardware modules in insert on the channel)... What could be the problem? Thank you! |
#2
|
||||
|
||||
Re: Different latencies when printing
Quote:
Can you post a screenshot of your Export settings? A video or screenrecording of your printing process would also be helpful. Thanks!
__________________
-Tope To create a support case with Avid Support, go to https://www.avid.com/learn-and-suppo...-music-support www.topedomingo.com |
#3
|
|||
|
|||
Re: Different latencies when printing
Quote:
Thanks |
#4
|
|||
|
|||
Re: Different latencies when printing
I am not following how you are using export here, if at all.
What exact modules are in the 500 rack? The Cranbourne is your playback engine, connected via USB? I want to check say you are not connecting via another interface and ADAT. You are using hardware inserts in Pro Tools right? and individually disable/enabling an insert? to do this printing? Each insert is going to the exact same insert I/O pair and processing in the 500 rack? there are not for example some going through the 500 rack slots, some out p/back through the ADAT ports, etc... that would be expected to have different latency. There are multiple bugs in Pro Tools ADC and latency handling, most can be typically worked around, but it can be a minefield to navigate. One bug happens with a plugin preceding a hardware insert with LLM and "sends persist in LLM" enabled. That will add a multiple of 1024 samples to the signal path. Also make sure ignore errors is not checked, that garbage should never be used, and can mess up track latency corrections. Is ADC enabled? I have written about using hardware inserts and ASIO/CoreAudio latency and hot to adjust ADC if needed in the past on DUC. Did you start by checking the ADC correction on the insert using a click or clap, just for a null/bypassed slot, certainly no digital cards in the slot. If the Cranborne reports correct latency data (ie the latency for the slots is correct and is reported for the initial IO input and output ports on the device) this should just align to within a sample. --- Other folks have reported problems in the past with Cranborne racks and latency, I have no idea what the causes were there, if they were real issues or not. Cranbourne may not be in a good position here since they are using USB Audio class complaint USB drivers on macOS and look like third party drivers developed by ToriLogic on Windows. Which raises suspicions that Cranbourne might have taken somebody else's interface card or design and integrated it into their box. I'd rather see interface vendors have strong in-house software/driver engineering skills. The Cranbourne documentation on latency stuff is kinda weird: (5008R User Manual Copyright 2019, no version number): "The issue with this concept is that there is no solid ‘latency’ figure that we can provide you. Latency varies entirely on the cpu power of your machine, the project size, the current buffer size, and the sample rate being used in the session. The actual round-trip latency figure will be different for every user." Say what? That is just so uh wrong. A good interface driver's job is to exactly report the standard sets of data about latency to the DAW and the DAW should account for everything. That works at least for the primary I/O on the interface with standard DAWs (and so I would hope works for the USB interface to 500 series slots). Do they mean because they ship a USB audio class complaint system it does not do report correct latency? And then their description of using Pro Tools inserts is not great, if needing to adjust for actual vs. driver reported latency differences, that really ought to to be done on the track ADC +/- setting. As I've written about on DUC many times. The Setup>IO>HW Insert Latency setting should be used for additional latency of any outboard digital processing gear added say in a 500 series slot. Maybe it's all fine, maybe not. I've never had a Cranbourne 500 series rack to check but this stuff starts to raise some concerns. --- It might be just your problem is caused by a simple user mistake, but I wanted to give a broader context of possible issues you might be hitting. If I was you I would definitely start by checking the ADC correction for a loopback HW Inserts on the Cranbourne and adjust if needed. And my comments/concerns/lack of knowledge about what Cranbourne is doing does not excuse Pro Tools for being a bug minefield here, or not having modern capabilities like a ping to easily correct insert latencies... (but that's all doable manually if needed with the ADC +/- setting after measuring the latency on a click/clap test). Last edited by Darryl Ramm; 11-14-2023 at 08:19 AM. |
#5
|
|||||||
|
|||||||
Re: Different latencies when printing
Hi Daryl, thanks for the precise answer (always very kind).
I think I didn't totally understand what you explained (not your fault), but I'll try to answer point by point: Quote:
Quote:
Quote:
Quote:
Quote:
Of course Quote:
Quote:
I'm thinking of changing DAW (I can't go crazy about these things every time, time taken away from music), but I don't want to argue... Anyway I try to record a video as soon as I can to show all the settings. Thanks |
#6
|
|||
|
|||
Re: Different latencies when printing
Quote:
Who knows what happens exactly. But there is a pretty significant bug (PT-293686) in Pro Tools that happens when you have a plugin before an insert, have LLM enabled, and have "allow send to persist during LLM" enabled. It adds some multiple of 1024 samples to the latency, and to what ADC reports. I suspect that 1024 sample multiple is likely coming from an error that has the signal flowing thought a disk I/O buffer (that is 1024 or 2048 samples depending on sample rate) instead of a HW buffer. Maybe a good idea for you to try to reproduce that bug on your setup so you see it and what exactly happens in your setup and can be sure you are not running into it. (I've not tried in a while to reproduce it, Avid support tells me engineering is still working analyzing the bug). Quote:
First check that Setup>IO>HW Insert Latencies are all set to 0 because at least to start with you are not going to use these (unlike the Cranbourne documentation says). Now in a new test session, with nothing else in it, no plugins etc. But using the sample rate and HW buffer size you want to work at.... and with ignore errors not checked. Take say a click track you have recorded to an audio track, add a hardware insert on that track and send that insert pair through you Cranbourne and back to Pro Tools, presumably you can just set the corresponding slot 500R8 bypass switch and have that act as a loopback. Feed the output of that track with the insert on it into another audio track inside Pro Tools and record that track. Compare the timing of the original click track waverform you see on the first track with that on the second. If Cranbourne has done its job correctly, the drivers will have reported the correct latency, and Pro Tools ADC would use that and the waveforms will exactly line up. I'm not aware of any Pro Tools bugs or cases where this does not work OK. But if they have not... measure the offset here, zooming in as far as you can and use the timeline cursor difference between matching zero crossings in the waveforms. You should be able to measure to one sample accuracy. The new waveform on the second track might alight perfectly, might lag behind the initial track (if the latency valuer reported by the driver were too small) or be shifted back in time before the signal in the first track (if the latency value reported by the driver was too large). Show the ADC values in the mix window and you can see how much Pro Tools ADC is correcting for the insert latency. Use what the offset you measured in samples and enter that into the +/- field and repeat the test and you should now see this line up. I'll leave workings out if you need to use a + or - value to you. Complication all this is that Pro Tools (and other DAWs) take the latency data interfaces provide for their first I/O ports and apply it to all ports on the interface. In this case all the USB I/O to the slots will have the same actual RTL latency, but the RTL latency say thought all the ADAT loopback is likely to be a bit less (since there is no ADC/DAC conversion. And this si a frequent cause of confusion. But in this case I would hope the interface driver would report latencies for those 500 slots you are using. A problem *might* be (and to be clear I don't know) that Cranbourne are relying on USB audio class compliance, don't have their own driver, and do not pass correct latency data at all. So I'm curious just what you see here. Even if the offset you measure is significant large you should be able to line stuff up correctly using the +/- ADC adjustment. Once you have this set up correctly, that same adjustment should be used on each track with a live 500 series slot hardware insert on it. You will have to remember to set it to 0 if not using an insert. The adjustment needed will change at different sample rates and HW buffer settings (and don't enable "ignore errors" as it that can cause latency errors ... that option maybe should be called "make errors"). And that Setup>IO>HW Insert Latency should be used only for additional outboard latency, say if you have a 500 series digital module with it's own additional delay. And I'm simplifying all this, there is actually a triplet of latency data that an interface reports for each output and input and Pro Tools will add those together and use to get the adjustment for ADC to apply. If things don't line up exactly it would be interesting to know all the fundamental data the interface is reporting and I can point you at (or may have to send you) an inspection tool from Apple that reports that. --- These two things above should help you get on a solid foundation, there may well be other issues happening, might just be a signal flow problem or a corrupt session etc. If the things above did not show up anything that helps I'd copy and start simplifying down a session that has a problem and try to get is as simple as you can, the causes of many latency issues often show themselves when doing that. Last edited by Darryl Ramm; 11-14-2023 at 05:45 PM. |
#7
|
|||
|
|||
Re: Different latencies when printing
Ok bros, you can download the video here:
https://we.tl/t-g7uMmEP8SL I found that there is no difference between when I insert ProQ3 plugin before the hardware and when I don't, BUT the latency to be corrected changes for each track (always passing the same module!) I am very annoyed by this situation. Every time it's a lottery and I have to waste a lot of time to align everything (imagine a project with 40/50 tracks to realign... ). Cubase doesn't have this problem. Logic doesn't have this problem. Reaper doesn't have this problem.... I'm really tired.... Thanks for your help and suggests Simon |
#8
|
|||
|
|||
Re: Different latencies when printing
ok, I prepared a video that I uploaded to WeTransfer, but I'm waiting for the admins to approve my post (maybe they need to check the video download link). I hope you can view it soon.
Thanks |
#9
|
|||
|
|||
Re: Different latencies when printing
Hi there! Have you seen my video?
|
#10
|
|||
|
|||
Re: Different latencies when printing
Quote:
--- Video are pretty cumbersome and annoying for non-UI related issues. I won't be looking at any more videos here. (and to be fair to Tope, your initial post with title "printing" might sound a bit like an export or bounce... and many problems there are folks selecting the wrong or unusual options and it helps to have screen shots/videos of that to see exactly what users are doing). Maybe the real value in the video is: You should turn on the ADC compensation view in the mix window. And lose the calculator and would work out how to use the click and drag of the cursor to measure time differences in samples (the "Length" display counter in the Edit Window). You also should not be using tab to transient to measure any latency to high accuracy, as I've described before *use a click signal*, zoom into that and look for matching zero crossings and measure the length between them. That should be a reliable way of getting sample accurate measurements. And you are eyeballing (possibly at maximum time zoom) exactly the samples where they zero cross and can be confident the measurement is valid. Sample accurate numbers can help a lot in diagnosing problems. I suggested you explore what is going on here but start by getting correct behavior by using the ADC +/- adjustments. The first part of the video just seems to show you have not done that. A video is not needed for that, follow the instructions I gave and post the results. Like: "I did a click test at xxx sample rate and xxxx buffer size. I needed to adjust the track ADC [+/-]xx samples to get alignment". The rest of the video I assume shows multiple inconsistent behavior with a plugin ahead of an insert might well related to the known bug I mentioned. But you have LLM not enabled so maybe you don't see that exact problem, but maybe there are related ones here. I had suggested you see if you can reproduce that other described problem, still seems interesting to do. You are using Fabfilter Q3 with potentially huge latencies, I assume you show it's behavior in different modes, but I'm not going to wade though the video trying to extract numeric results. How about starting with a basic plugin with known fixed latency. Does Pro Tools properly handle Q3 alone as a plugin insert changing it's latency? -- It should but it is worth checking.. maybe you well know that from lots of use of Q3, I have no idea, and I've never used Q3. The useful stuff here to try to debug a problem is likely just a table of results of several plugins inserted ahead of a H/W insert or used by themselves and what their claimed latency (shown in the ADC window) is and how far off the results are. It's maybe a couple hundred bytes of data at most, no more videos please. And if you are looking for work around, then have you tried printing or committing up to the plugin then adding the hardware insert? (and use that +/- ADC value you work out to correct any issues with the Cranbourne reported latency). Last edited by Darryl Ramm; 11-16-2023 at 01:17 PM. |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Latencies! | joy4u | Pro Tools TDM Systems (Mac) | 2 | 01-17-2001 11:53 AM |
Latencies! | joy4u | General Discussion | 1 | 01-16-2001 10:52 PM |
Latencies | joy4u | Tips & Tricks | 0 | 01-16-2001 08:18 AM |
Plug In Latencies? | Eric Bazilian | Tips & Tricks | 8 | 01-03-2001 09:33 PM |
Recording Latencies | Frankus | 003, Mbox 2, Digi 002, original Mbox, Digi 001 (Win) | 2 | 08-21-2000 08:32 AM |