Check Latency broken on latest develop build?

[dannytaurus]

@David-Healey Before export, in HISE.

[dannytaurus]

@David-Healey Pretty sure this was the post:

https://forum.hise.audio/topic/14160/latency-compensation-not-being-triggered-in-daw?_=1783073938002

It was a pitch shift node, which has larger latency the more you shift.

[David Healey]

@dannytaurus said in Check Latency broken on latest develop build?:

@David-Healey Before export, in HISE.

So it doesn't need to be realtime?

When you click export HISE could run through all of the latencies, find the highest and embed the setLatencySamples call into on init. Would this achieve the same thing?

[ustk]

Don't rely on a single-sample impulse unless you're dealing with a very basic processing chain, especially if there's a non-minimum-phase EQ involved. An impulse measures both the plugin's algorithmic latency and the filter's frequency-dependent group delay. The latter isn't processing latency, it's just how the filter behaves.

A more reliable approach is to record a sine wave (or another suitable signal, noise, etc...) and compute the cross-correlation between the bypassed and processed signals (that's what my app Align-IT is all about). It could be implemented in Hise as this would be much more reliable with noise (but not random because it obviously needs to be the same fro dry/wet buffers for a correlation to exist)

Every time I tested the latency check in HISE (which is actually how I measured it before the feature was implemented), it failed as soon as a non-minimum-phase EQ was in the chain.

You can reproduce this in any DAW: send both an impulse and a sine through the plugin, record the outputs, and compare the measured delay. You'll see the difference.

Also keep in mind that with non-minimum-phase EQs, the apparent delay depends on frequency. There's no single latency value that applies to every signal. But noise is the closest we can get (in fact it would be even better with a weighted noise but that's going too far)

[ustk]

@David-Healey Keep in mind that algorithm delay changes with samplerate (so if you have adjustable oversampling nodes or fix buffer nodes it multiplies the number of different latencies by the same factor). All those cases needs to be computed and stored in the script.

[ustk]

With an error of 3 samples at 48khz and you are already comb filtering at 16khz. Using an impulse to measure some signal chain can easily throw a result that is off by 20-30 samples, so as low as 1-2khz... that is more than a muffled sound

[Lindon]

hmm, bummer I think...

I have a very big multiFX (over 50 different FX) product that can have up to any of the 50 in 6 different slots in a chain, I need to assess the latency for each FX - yes there's a fair few EQ's in there too...

I was hoping(ha ha ha) for a simple(ish)way to assess the latency -

[dannytaurus]

@ustk said in Check Latency broken on latest develop build?:

With an error of 3 samples at 48khz and you are already comb filtering at 16khz.

Wow, I never thought of it like that!

[dannytaurus]

@David-Healey I defer to @ustk's vastly more detailed knowledge here

[ustk]

@dannytaurus That being said, it only matters in a parallel track mixing context (but nowadays it's still very frequent, we parallel this and that everywhere...), but you don't mind such a small latency for instruments...