M4 -and- Very High NDSP Plugin Latency Question?

[Alexi]

Hi all !

Firstly, happy new year to everyone and I hope the year goes as well as possible for you all

Background.

I sprung for a Macbook Air M4 to use with my Focusrite 4th Gen Solo running 5.1.6.

Running Tahoe 26.2 with the Focusrite Mac Kernel Extension [ KEXT ] Driver - instead of the “normal” Mac Driver.

Overall system RTL latency is around ~3.8 ms at 96k / 32 Samples.

See Pic 1 - the Two Notes Genome Plugin I use with my NAM Captures loaded

See Pic 2 - I then replaced Genome with NDSP Nolly and got this

I am not clear how this Nolly 1.8ms Latency “works” in the context of the whole system (?)

Questions

(1) is the Nolly 1.8ms added to my existing overall 3.8 ms to make it 5.6 ms in total RTL for my whole system ?

-or-

(2) as the Nolly 1.8 ms is lower than my pre-existing 3.8 ms RTL, is the Nolly 1.8 ms absorbed into my overall 3.8 ms RTL so that it stays at 3.8 ms RTL even with the running latecny of NDSP Nolly ?

(3) or is it a “quirk” of running the MAC Kernel Extension Driver as opposed to the “normal” MAC Driver (?) - I seem to recall that on my Windows machine, the NDSP Nolly Latency was only 16 Samples / 0.1ms (?)

Hoping this make sense (?)
Alexi

[rank13]

I wonder if the pitch shifting they’ve started to add into the plugins is the reason for the larger samples?

[Alexi]

Hey. There’s no clear / obvious / possible way I can see to turn it off (?)

Also - as I noted / seemingly remembered, the exact same Nolly Plugin in GP5 in Windows 11 used approx. 16 Samples / 0.1 ms (?)

[rank13]

It was the “X” version on your other machine?

[rank13]

Another point of comparison is to try the AU version of the plugin and see if gives the same results.

[Alexi]

I recently updated to the “latest” version and got this “X” version in my download folder from NDSP ??? which I did (?) think was weird because I thought (?) the “X” plugins were only for the QC.

I hadent evn bothered to check for updates in ages.

Yep. The Windows machine was running the “old” non-X version.

I also tried the “AU” version and exact same very high latency ?

[rank13]

I believe the “X” versions mean they are QC ready, but there is further work to actually port them to the QC.

I also think features like the Transpose were only added to the older plugins with the X version. It’s still a guess, but if your Windows plugin doesn’t have the Transpose control, then I suspect the higher plugin latency is due to this.

[Alexi]

Thanks rank13

Its a crazy high latency “hit” - 1.8 ms at 96k is massive compared to Two Notes Genome with every slot filled including running a full HQ NAM Capture … and its 0.00 ms !!!

Do you have any insight or knowledge about how GP5 handles this CPU Latency ?

• is the Nolly 1.8 ms “added” to my pre-existing 3.8 ms RTL** so my new RTL is 5.6 ms, (?) -or- is the Nolly 1.8 ms absorbed within my overall 3.8 ms RTL so that it stays at 3.8 ms RTL in total even with the 1.8 ms running latency of NDSP Nolly ?

All the best

(3) or is it a “quirk” of running the MAC Kernel Extension Driver as opposed to the “normal” MAC Driver (?) - I seem to recall that on my Windows machine, the NDSP Nolly Latency was only 16 Samples / 0.1ms (?)

[Frank1119]

A plugin host shouldn’t ignore the latency reported by a plugin: the plugin is reporting it to make sure that a sample that follows parallel paths arrives at the end of all paths at the same time.

So one plugin reporting latency affects the whole setup.

As far as I know, for pitch shifting there’s always latency involved, because there’s a need for a small buffer to analyze. It is possible that a plugin for pitch shifting just fails to report the latency: then the latency is still there, but the total setup isn’t affected. I know that Reaper has a setting to just ignore latency reported by the plugin (but that won’t help you very much).

[Alexi]

Thanks

I just ran the GP5 RTL Tool with the Cables Plugged in as recommended and got

Interestingly, you wrote:- " … A plugin host shouldn’t ignore the latency reported by a plugin: the plugin is reporting it to make sure that a sample that follows parallel paths arrives at the end of all paths at the same time. "

In my case the above 3.1 ms actual real-world RTL reading was the same in this full NDSP Nolly Rack compared to a fully empty rack ???

So … am I right in assuming then (?) that the GP5 RTL test only tests the IN / OUT of the Audio Interface and does not take any account of any VST’s loaded in the GP5 Rack that is open during the test run ?

If this is the case, is there a way to test

(a) if the 1.8 ms Nolly NDSP is “showing” is “real” / “accurate” (?)

or

(b) if it is being “misreported” (?)

or

(c) if it is running in parallel within the overall system 3.1ms RTL and therefore not impacting the GP5 Latency test as it is below the systems 3.1 ms total real world RTL Latency buffer ?

or

(d) is any Latency in any GP5 hosted VST3 always additive / linear ? ie: 3.1 + 1.8 = 4.9ms ?

Thx

[Vindes]

I can’t help you with your specific Nolly questions, but I can review some of the math and maybe make how it works more clear. (At least how I think it works, I can’t say if anything is different with the Mac.)

At 96khz every sample is (1/96000) seconds, or about 0.01 ms.

A 32 sample buffer works out to 0.33ms, and if you’re measuring round trip latency you have 32 samples going in and going out. So combined that’s 0.67ms that your sample buffers add to latency. That represents the fastest possible round trip.

In practice all device drivers are going to add to that. If you are measuring 3.1ms then the difference between the hardware buffer times and what you measure is generally going to be your driver overhead. In your case that would be 3.1ms - 0.67ms = 2.4ms.

To put these figures in perspective, it takes sound 1ms to travel 1 foot. And since you’re measuring round trip, what you’re actually going to hear when playing a keyboard is going to be roughly half of that. So if your one-way latency is 1.5ms the impact of that is about the same as moving 1.5 feet further from your speakers.

If you are moving around on stage during a show and regularly moving between 2 feet and 15 from your feet from your monitors then you are adding a variable latency of 13ms as you move around. I just say that to put what “Very High” latency means in real world terms.

In audio apps like GP different plugins report their individual latency contributions. Many report zero, but others will report higher numbers. Those reported figures will always be additive to everything discussed above in a live playing situation.

What GP will attempt to do is determine the added latency of the longest signal path in your wiring diagram. So let’s say you have two VSTs set up in parallel. Your guitar signal comes into the wiring diagram and splits so that one branch goes to a VST reporting zero latency and the other to a VST reporting 100ms latency. From there they merge and go to your output.

In that case GP will delay the faster signal path by 100ms to ensure that the two paths are in sync when they are output.

Every time you add something with latency to that longer signal path, GP will compensate by adding latency to any shorter signal paths so that everything remains in sync when it is output.

As far as I know, none of that is going to show up in the RTL test of GP because GP is just testing your interface there, not your Rackspace.

[Frank1119]

@Alexi

So … am I right in assuming then (?) that the GP5 RTL test only tests the IN / OUT of the Audio Interface and does not take any account of any VST’s loaded in the GP5 Rack that is open during the test run ?

Yes. The latency tester doesn’t do anything with the plugins in the wire view. You would have to use multiple interfaces to get that measured.

I’ve tested whether GP honors the reported latency: It does. To test this I created a plugin reporting it introduces 10 seconds latency (it actually passes through the incoming audio unprocessed whatsoever).

In the picture above you can see that the left channel is delayed by GP.

@Alexi

(a) if the 1.8 ms Nolly NDSP is “showing” is “real” / “accurate” (?)

Whether it is accurate or not doesn’t matter: GP will still take in account the reported latency for the parallel paths

@Alexi

(c) if it is running in parallel within the overall system 3.1ms RTL and therefore not impacting the GP5 Latency test as it is below the systems 3.1 ms total real world RTL Latency buffer ?

That is difficult to test, but I assume it will be added to the latency which is already there. May @dadi has any thoughts. My guess is that you will not ‘get iucky’ in this respect

@Alexi

(d) is any Latency in any GP5 hosted VST3 always additive / linear ? ie: 3.1 + 1.8 = 4.9ms ?

It will be linear: The appropriate buffering will be done by the host (GP) and these buffers will exactly hold the number of samples of the overall added latency

@Vindes

To put these figures in perspective,

To be honest: I think 1.8 ms latency for a pitch shifter is very decent. A lot of pitch shifters needs higher latencies to get a reasonable sound quality

My 2 cents. I could be wrong (it happens)…

BTW: I use Archetype Tim Henson: Latency 1.5 ms (48Khz)