9ms is a relatively long trip time.
There’s no issue using it for FOH, but you have to be very careful when using it for monitors. I think 4ms to 9ms is unacceptable for monitor mixes
Depending on your setup, it’s definitely possible to create a system with a round-trip-time of less than 9 ms; with 1 ms Dante network latency and 32 sample periods at 96 kHz, we would expect to see a 3 ms total insert latency (1 ms network each way plus 1 ms internal latency), plus whatever latency your console routing or AD/DA conversion is adding. If you’re seeing significantly higher latencies than that, are you running at a lower sample rate perhaps? Have you measured thee insert latency of just your interface?
Today I measured my system too. I´m @48k and have 4.2ms roundtrip through the engine. single mono chain, no plugins. Period Size 32 Samples, Dante 1ms. So the Latency is build as follows I guess?
1ms Dante IN
2.2ms System Latency
1ms Dante OUT
Is that correct? Only way to make it a bit faster is to go to 96k where I could win kind of 0.7ms, right?
I measured today using a Yamaha Rivage PM5>Hy144…
Comparing using smart, no insert channel & insert channel through the Fourier. I was getting 6.08ms round trip with no plugins. So far I only have racks with 1.25~ ms on them and those plus the 0ms ones are keeping the average around 7-8ms per rack with minimal plugins.
I have also noticed while delay compensating on the console to line everything back up that the bypass button on the plugin, it doesn’t change the path length or it keeps the plugin in the time calculation.
If you however use the bypass on the bottom, it takes it out of the latency path.
My workflow is going to involve loading insert chains on busses and trading bypass states to make the chains more versatile. So keeping the chain path length was important.
Anyhow just some stuff I found today while testing.
Assuming you have Dante device latency set to 1ms and using 32 period size, the minimum roundtrip at 96kHz is 3ms, and 4ms at 48kHz.
Can you confirm these settings? If not, there must be something outside of the transform.engine that is adding latency to your round trip.
The bypass function in the transform.client deliberately removes the latency of the plugin. This is really useful for example, when you want to switch between 2 reverb plugins in the same chain, you can have both running and jump between the 2 without loss audio. But at the same time not wanting the latency of the 2 plugins combined as they will not be used together.