5.01 - delay compensation on sends

[Vance]

ok here's the deal...

1) take a track and turn the send gain to send channel A to 0db...

2) set output of send A to sends only and turn the send B gain up to 0db

3) there is a noticeable delay between the two tracks, even with delay compensation turned on and no plugins on any tracks anywhere...

is this a limitation of the send/delay compensation architecture of live? what are the chances of this delay being eliminated in future updates?

[Andreas Zapf]

Hi Vance,

does the delay persist when you route the audio through the sends the other way round (from the player track to send B and then to send A)?

Regards,
Andreas

[Vance]

OK been testing this further and ive noticed it's present no matter what order you send the tracks in... it will occur when:

1) a track is output to Master and is sent to one send (say, send "X"), and
2) send X it output to Sends Only and is sent at 0db to another send (say, send Y"),

and also,

3) at least one plugin is present on the first send track in the chain (send "X")... there is latency if a plugin is present on send "X", there is no latency (i.e. it is properly compensated) when there is no plugin... the latency occurs even when the plugin is turned off

just discovered point number 3, so it definately looks like a bug rather than some kind of normal consequence of the engine routing or whatever...

[Dandruff]

1) take a track and turn the send gain to send channel A to 0db...
2) set output of send A to sends only and turn the send B gain up to 0db
3) there is a noticeable delay between the two tracks

confirmed here (live 5.0.1 demo). tested with operator. but it happens only when inserting a plugin with delay (tested with compressor II and 10ms look ahead) into send A. output of send b is delayed. that shouldn't happen with pdc.

[Dandruff]

does the delay persist when you route the audio through the sends the other way round (from the player track to send B and then to send A)?

yes (with a plugin that causes delay in send B, even when it's disabled).

[Vance]

to build on Dandruff's comment: if a zero-latency Live plugin is inserted on send "X" then there is no delay... but if u use a plugin with latency like compressor II with lookahead then the delay is noticeable...

but with VST plugins, there is a very noticeable delay no matter what the latency of the plugin... even zero-latency plugins like the sonalksis EQ produce a large latency (larger than compressor II with 10ms lookahead)

also, to add to the description of the bug, placing a plugin on the second send (send "Y") doesn't introduce any delay at all for me... i.e. if you send an audio track to send X, then output send X to Sends Only and send to send Y, putting a plugin on send Y introduces no latency (it is properly compensated)

[Andreas Zapf]

Hi all,

this is a known issue resulting from the fact that send-to-send routings are feedback connections.

I'll try to explain it: When Live does the calculations for delay compensation it assumes that all send volumes in all player and send tracks are turned on, meaning that there is feedback between all sends. Delays in a feedback signal path cannot be compensated, it's simply impossible. So Live must ignore connections between sends for the delay compensation calculation. As a result, when you "chain" send tracks as described, delays in send tracks in the "middle" of the chain won't be compensated.

A solution could be to re-compensate delays whenever a send knob is turned from or to -inf dB, so that only audible feedbacks wouldn't be compensated. However, this would introduce several problems, for example that turning a send knob could change the latency of other tracks, leading to crackles and other undesirable things.

If you need chains of tracks that are properly compensated, you may want to use routings between player tracks. Such routings will be always compensated correctly (unless you create feedback, as said above).

Best regards,
Andreas

[Dandruff]

alright. thanks!

[eddu]

If you need chains of tracks that are properly compensated, you may want to use routings between player tracks. Such routings will be always compensated correctly (unless you create feedback, as said above).

Best regards,
Andreas

Andreas,

Maybe my problem is not exactly this, but when i route a track to another player track and record a clip i always get a small delay in the recorded audio (the sample begins a bit later and i always ahve to move the beginning a bit to the right to make the clip really fit into the tempo). As far as i know this has nothing to be with latency because no conversion (a/D, real recording with the audio interface) is hapening, it´s only bouncing one track to another one. Delay compensation is activated and 512 is the value of the buffer size i´m working at.

Thank you.

[Vance]

Thanks for the explanation Andreas!

I stumbled across the bug because I was trying to use sends as a bus/group channel for some drums and then send it to a send effect, but I suppose using an Audio track as a bus instead is the best option to avoid the problem...

[djsynchro]

It also happens to me... if I record a VST or Live device to an audio track (internally via "resampling" the audio is a bit late. Why?

[eddu]

In fact i don´t use the Resampling option, I only make one output´s track go into the input of another one and record there. But anyway i think i used the Resampling in the past and gave me the same problem as well.