If you are using the I/O Plugin or External Instrument plugins in Logic, latency is a non-issue because Logic's external latency compensation actually works correctly. I/O measures round trip ping and calculates using that value, and External Instrument is applied automatically without user generated measurements.

By him even mentioning "shifting the audio" to account for latency, means none of this has even been tested. Otherwise it would be obvious that Logic's external Latency Compensation works accurately. The Logic Sample Delay plugin works perfectly, in either milliseconds or samples. It can be used as an offset value for any audio track which has been recorded already, or just to even add as little as a single sample if you are trying to get a Haas effect. Midi and Audio channels can both be positively and negatively delayed by the same nearly-microscopic amounts in each channel's Region Inspector.

There are reasons to need this feature in Logic. (recording delay). In no situation mentioned so far, do they even apply here. Furthermore, as I already mentioned; that value is entered as sample number, not in milliseconds.

Go ask David Nahmani on his website. See what he says. He writes the books on Logic. https://www.logicprohelp.com/logic-pro-book/

 

Last edited: Nov 7, 2024

That's wrong, such a situation is actually mentioned here. Logic corrects by the value it gets reported by the audio interface driver, and this works perfectly with my tested RME interfaces for example, because they always deliver the correct value they actally use and that can be measured with RTL Utility or Logics Ping test. Ping will always be zero for a direct audio loopback by cable. You can even read about all this in RMEs manuals. The driver reports the exact value for an analog connection through the internal DA and AD converters. If you connect an external converter via ADAT, an offset may occur, because the interface does not know the delay of the external AD/DA converters.

The Babyface Pro FS for example has 5 samples AD and 7 samples DA delay. If you connect an old slow converter like the RME ADI8 AE for example which has 38 samples AD and 44 samples DA you get an offset of +69 samples and have to correct that as recording delay to be sample accurate. These values are constant, so you can calculate and/or measure it and set it one time for your setup.

Now as tommyzai mentioned, he gets slightly different measurements everytime he starts RTL Utility, so the Audient interface has a slight offset of this value that's different in every session. That's the same I noticed with the UMC204HD I tested. To be sample accurate, you would have to measure it after every audio driver restart and correct this offset as recording delay in the same way he already did with Reaper.

Sorry for having opened pandora's box by using the word "jitter" when I wrote latency jitter, which is a big red flag for all audio enthusiasts and often results in endless discussions, but RME also calls this "latency jitter" and mentioned it and how they prevent it to happen in every manual I can think of, and I started using an RME Multiface/Digiface with an HDSP PCI card in the early 2000s.

 

Hi Radio, I'm sorry to chime in like this again, but this is again not the problem of the OP and the link has absolutely nothing to do with the slightly changing latency offset he gets.

We found out that his Audient interface is giving a different RTL measurement every time he restarts it, just the same as I experienced with the UMC204HD and also other interfaces years ago on Windows.

 

You don't need no ShitGPT, my brain says 1000ms/96000samples = Xms/170samples -> 1000ms/96000samples x 170samples = Xms. X = 1,77083...ms

 

You're right. But it is a nice and lazy way to answer lazy questions. Correctly, I might add. I mean, who knew the AI would be capable of math taught to high school students in Algebra 1? That might occur to the OP if he wasn't just interested in wasting other people's time. Maybe sarcastic works better? https://lmgtfy.app/?q=samples+to+milliseconds+conversion&iie=1

 

Last edited: Nov 7, 2024

I was at 7+ms before, now at 5ms w/o off-set. With off-set, I am at . . . near zero. All is well. Thanks for your help.

 

I will try to test this later today with my e-mu. I have to open it to install new zulu drive in it anyway. It's the only hw I have left with analog ins/ADAT. Aside from my interface, obviously.

As I stated previously, none of the scenarios OP is discussing require this. He is simply looking at numbers on a screen. I can come up with plenty of imaginary scenarios when things like this matter. OP is yet to present one. The real source of the problem is likely just his playing chops. He's not the only Logic user with a $200 interface who would need to do this, over the span of 3 or 4 threads.

 

Last edited: Nov 7, 2024

I agree, and most users wouldn't care about 2 msec latency jitter or would try to measure anything before actually working with it. They would start trying to fix problems as soon as they actually occur in their workflow.

But being an audio technician and developer myself I'm always interested in the origin of such problems. That's why I like RME that much, they really give you technical specs and not just marketing speech. And I expected more of a company like Audient, they should be able to develop precise drivers. Sure, it's not RME price range, but also not Behringer.

 

It also depends on use case. I still got two of these old RME ADI8 AE converters using those slow converter chips, which is a rather drastic example for slow converters. Combining one of these with my Babyface Pro FS to record 12 channels in parallel leads to an offset of 33 samples between the BF and the ADI8 channels. It's not much, but it's about 25 cm distance you better calculate in when multiple micing drums.

Edit: Also got a Behringer ADA8200 in the rehearsal room, it's really good for it's price, mic pres are ok and it's fast, only 8 samples slower than the Babyface Pro FS, that's 6.2 cm distance at 44.4 kHz.

 

Last edited: Nov 7, 2024

Phew, in my opinion this is a hasty prejudgment of the Audient iD14 company. I lack clear written evidence.
I ask you or Audient user @tommyzai to provide clear figures, photos from the RTL etc.

I am an Audient ID14 & Audient ID14 MK UII user myself and am of course interested in whether there is a driver or manufacturer error. If there is evidence, I would also contact Audient's technical support and ask for a statement on the problem from Audient.

So far I have only read vague assumptions and I ask you again to provide evidence / measurement results in the form of photos, for example.
For you @Myfanwy, the negative verdict against the Audient company is made too quickly. I would like to clarify and dispel false claims based on measurement errors and botched measurements.

Let's find a way to find out the truth and not prejudge and disparage the Audient iD14 manufacturer, saying they sell bad drivers or a bad product. I say Audient ID14 is an excellent product until they prove me wrong.

 

Wow, didn't know that, but it's brilliant! I've got no access to any Audient device, only a good friend asking me if I would recommend it compared to RME because of the price difference.

I don't say they are selling a bad product or faulty drivers, it's just about accuracy. You can buy laser distance meters in every tool shop, and if they are a few centimeters off, no hobbyist cares.

So if you could help me with a very simple test, we could bring light into the dark and maybe also help the Audient developers:

First of all, you are on Windows, right? So this only applies to the Audient Windows ASIO drivers and not to the Audient macOS drivers. But let's just start. Connect an analog out to an analog in of any of your devices, start RTL Utility and run the test at a given configuration, let's say 44.1 kHz, 64 samples buffer size. On Windows, you have to set the buffer size globally in the driver settings.

Note the measured RTL and the reported RTL, these should be identical, if not, that's the first sign of incorrect drivers.

Now, set the sample rate to 96 kHz and repeat the test, then set it back to 44.1 kHz and repeat the test. Be sure that the buffer size is again at 64 samples, because some drivers raise it if you set a higher sample rate and don't set it back.

Note the measured RTL and the reported RTL again, if these were identical in the first test and now are also identical, everything is fine.

If not, repeat this procedure and note the offsets you get, so you will know how much latency varies.

 

Thank you for your cooperation and your detailed instructions! I'll let you know when I've finished the test.

 

this really is a basic knowledge of audio editing

 

I know, it's very far off topic, but I just pulled out my ancient RME Digiface with an HDSP ExpressCard34 in an old Sonnet Express Card to TB2 enclosure I got for a few bucks on ebay and connected it to my MacBook Air M1 with a TB3 to TB2 adapter, downloaded RMEs drivers and connected the Behringer ADA8200.

I get consistent 237 samples of RTL at 64 samples buffer size and 44.1 kHz without glitches or latency jitter, that's 5.37 msec RTL with a more than 20 years old interface. That's RMEs driver support.

Edit: I started using the Digiface with an HDSP PCI card in my studio Win PC and a CardBus card in an early 2000s Win laptop on the road, later for some years still in a "Hackintosh" with the PCI card after Apple dropped support officially. Later on with a PCIe card and even more later with the above mentioned ExpressCard34 to MacBook Air M1 configuration.

So am I really asking too much of a developer to create decent drivers in 2024?

 

Last edited: Nov 7, 2024

@tommyzai, can you post your results from "RTL_Utility_" here? Pictures would be very useful!

A new firmware update v1.1.2 is available for the Audient - iD14 MK II.
- iD14 MKII - Firmware Change Log V1.1.2 [Changes: Bug Fix: Talkback assignment affects Main Mix]
Source; https://support.audient.com/hc/en-us/articles/4406464772628-iD14-MKII-Firmware-Change-Log

The Last Driver is: iD-v4.4.0b3 --> https://audient.com/products/audio-interfaces/id14/downloads/

 

Last edited: Nov 8, 2024

Damn, you people are making this overly complicated. It's very simple.

1. Find the time for each sample:
Time per sample = 1/Sample rate = 1 / 96000 = 0.0000104167 seconds

2. Multiple by the number of samples:
0.0000104167 x 170 = 0.00177083 seconds

0.00177083 secs is just 1.77083 milisecs