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.
Hi Andreas,
I’m sorry to hear about your experience, this is definitely not standard behaviour and we would like to investigate this. Is there any chance you would be able to contact [email protected]? If you could provide your transform.engine Logs, transform.client Logs, and a brief description of your networking setup, the team would be happy to resolve these issues.
I just want to clarify that the Dante latency setting is fixed and does not increase based on DSP load or transform.engine activity. Once Dante latency is configured, for example to 1ms, that value sets a fixed buffer on each end of the Dante stream and stays constant regardless of what is happening inside the engine.
The internal latency of transform.engine is determined by the period size and sample rate. For example, a 32-sample buffer at 96kHz results in approximately 0.33ms of processing time (DSP Budget). Even under load, this does not increase. If the engine cannot complete processing in time, it will cause audio glitches or dropouts rather than silently increasing latency.
So the 3ms round trip figure (1ms Dante in, 1ms engine processing, 1ms Dante out) is not theoretical. It reflects real-world performance, and we have many users operating in these conditions!
Any further questions, don’t hesitate to reach out!