Total Latency of a Live Set

[phränki]

Hi! The search didn't find an appropiate thread here, so my question to Ableton Live 11.1 is:

Is it possible to find out the total Latency of a Live Set? By this I mean the Latency value in Samples and Milliseconds, that Live is compensating through the Latency Compensation. Other DAWs like Reason and Reaper do display the total compensated Latency value of their projects.
Just to clarify: I don't mean the individual Latency of a Device inside a Live Set (which is displayed in Live's status bar). And I don't mean the global Latency of my Audio Driver (displayed in the Audio Preferences).

It would be even more awesome to find out the Latency of the invidivual Tracks and Chains in the Racks.

Thanks in advance!

[[jur]]

You have to do the maths by yourself. The Set's latency is equal to the highest devices' chain latency.

[Greenapples2019]

Thanks [jur], it's an interesting topic. So are you saying that if a track has devices creating 4ms of latency, and it feeds into the Master which itself has devices which create 6ms of latency, then the overall project latency is 6ms rather than 10ms?

[[jur]]

Thanks [jur], it's an interesting topic. So are you saying that if a track has devices creating 4ms of latency, and it feeds into the Master which itself has devices which create 6ms of latency, then the overall project latency is 6ms rather than 10ms?

Yes indeed. Because the device that has 4ms latency has enough time to do its thing before the 6ms one completes its "cycle". They don't need to add up.

[[jur]]

Sorry, I said something wrong. Of course the Master's latency is added since there's the routing... my bad.
What I was saying is that if track A has 10ms and track B has 20ms, those don't add up and the latency will be 20ms.

[Greenapples2019]

Brilliant, thanks for explaining/clarifying, so it's all about the weakest chain in the link, so to speak...

[fishmonkey]

Brilliant, thanks for explaining/clarifying, so it's all about the weakest chain in the link, so to speak...

to be clear, for audio processing that is running in parallel, yes. for processing that is running in series the latency is additive.

[phränki]

You have to do the maths by yourself. The Set's latency is equal to the highest devices' chain latency.

Yes in a simple Live Set I would just calculate. But in case of a very complex Live Set (in my case designed for up to 3 hours performance) with loads of Racks, many Side Chain routings, input monitoring and the "Reduced Latency for Monitoring" setting activated, it's hardly possible to just add the latencies up.
For instance I found that a certain Effect Rack shows a high latency in the status bar (around 20 ms), but the containing individual devices all show 0 ms. I assume that the reason therefor is an External Input sidechained into on of the devices. But I'm not sure.
From such a point it's getting tricky, you know

Maybe someone heard of a M4L hack for this (if M4L is capable of this at all)? I'll do some research...

[Calagan]

+1
It’s not always possible to check each track to figure out the global latency.
It could be great to have a way to know that automatically (and I don’t think it’s a complicated feature)

[Greenapples2019]

On a related topic, Ableton seems to include a device's latency in the Delay Compensation calculation, even if the device is disabled. Is there a logical reason for this, and any way round it?

Also, if I set my buffer size to 128 samples, and the only plugin has latency of 64 samples, does Ableton process the plugin within the 128 samples, or is it in addition i.e. effectively 192 samples?

Thanks in advance for your knowledge!

[johnbongaarts]

Agree this would be very helpful to find easily. I find it particularly annoying when a longer effect chain is adding a lot of latency such that my meters and even transport bar are all offset significantly from what I'm hearing. Makes the tools a lot more cumbersome to use, so if it's easy to get a ballpark of the overall set latency (basically as a quick measure of the displacement) that would be helpful and indicate I should do something about it.

Having indicators of particular chains of latencies would also be helpful, but it can get convoluted with lots of chains and really as was mentioned before, the worst offenders are the most important to quickly find. Usually that correlates with the CPU load, but not always.

Indeed, I believe the total latency will always work out to the sum of all the worst case latencies in all chains executing serially, where any of those chains that have channels being processed in parallel will have a latency equal to the max latency of the channels executing in parallel.

Testing my own understanding with this simple-ish example: Kick drum with 5ms latency being used as Post FX sidechain input to both a Bass channel with 3 ms latency and Synth channel with 14 ms latency all having sends (post fader) to a return channel with a reverb that has 20 ms latency, all coming together to a main channel with 30 ms latency, with a driver/interface that has 12 ms output latency.

5 ms (from Kick) + 14 ms (worst case from bass and synth in parallel) + 20 ms (return latency) + 30 ms (main latency) + 12 ms driver output latency would mean a total latency of 81 ms. In practice, this means the transport bar is running ~81 ms ahead of what you hear in your monitors. As far as the meters go...I guess this would all depend on where in the chain, but the main meter would be ~69 ms behind the transport, and so on backing up from there.

[evon]

Imo, if it sounds good, then it is good. Latency is good, controlling it helps to give the human feel and also helps with stereo separation.