Check Latency broken on latest develop build?

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...

dannytaurus

@ustk Dug into this and found the root cause. Two PRs are up that fix it:

What broke: since e429f19d1 (Jan 11) the IDE builds with a 16-channel configuration, which disables FORCE_INPUT_CHANNELS - and with it, the path that carries the input buffer into the signal chain. The latency check injects its test impulse into that buffer, so the impulse never came back: no result popup until you play a note, and then the number is just the elapsed time. a6c5d9dd7 fixed an include-order problem in the same area but the input path is still compiled out in the stock build, which is why the tool stayed broken. PR #1013 keeps the input alive during a measurement (no-op the rest of the time, backend only).

Second problem: even with the signal path restored, the old single-sample impulse can't survive effects that smear transients. Something like pitch_shift spreads those two samples over its whole analysis window and the output peak lands ~50x below the detection threshold, so the check hangs forever. Following @ustk's suggestion, PR #1014 swaps the impulse for a 20ms sine burst at 1kHz and reports the onset (first threshold crossing) instead of the peak. It also adds a 2 second timeout with an explicit "no signal detected" error instead of waiting indefinitely.

Test results with both fixes (48kHz, stock standalone build):

fully wet 333ms delay: 16000 samples, exact and repeatable
convolution reverb: deterministic result that measures the onset of your IR (the convolver head itself is zero latency, so silence at the start of the IR file is what you're seeing)
pitch_shift: now reports (~4200 samples); the remaining +-250 sample spread between runs is the stretcher's own timing indeterminacy, not the measurement

One side discovery while testing: wrapping pitch_shift in an oversample4 node cuts its real-world latency roughly 4x (~88ms down to ~23ms), because the stretcher window is sized in samples, not milliseconds. Costs you the CPU of running it at 4x rate, but useful if the latency matters.

Check Latency broken on latest develop build?

24

2.5k

13.9k

121.0k