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.
Thank you for your measurements,
So as far as i noticed,
The DAD 256 solution is more or less the same with Dante as the Transform engine. So would also be around 6ms when used on Inputs and busses.
Of course MADI will always be quicker because it is a simpler kind of architecture.
Each Type has its Advantages/Disadvantages.
But another question:
Do you get stable results with Dante Latency of 0.25ms?
Or was is just for measurement?
Experience has shown that a Dante latency below 4ms and a sampling rate below 64 does not allow error-free operation. The information from Fourier is theoretical because as soon as the TE has to work a little, the Dante latency increases which leads to audio errors.