Latency in Return Tracks

[ScottV]

I brought this up last year, and I'm bringing it up again.

Why is there latency in the Return tracks?

Seriously. Am I missing something?

I know of work around's but they either hog CPU usage or don't give me the results I'm looking for. Why is this a problem? Please SOMEONE help with this.

[timothyallan]

Depends on your a. projects routing and b. plugins used

With a fresh project with nothing in it, do you still get latency?

[Rave]

I brought this up last year, and I'm bringing it up again.

Why is there latency in the Return tracks?

Seriously. Am I missing something?

I know of work around's but they either hog CPU usage or don't give me the results I'm looking for. Why is this a problem? Please SOMEONE help with this.

What r your work arounds ?

[Khazul]

Do you have a return track routed to something other than the master?

If so - disable the corresponding send on the track its routed to.

[[nis]]

There will be latency (*) on a return track if you route the return track's audio back into another audio track. The following problems will occur:

1. Such a routing can cause an infinite feedback loop, because you could (in theory) use the audio track's SEND controls to feed the signal back into the return track and so forth. In this case, Live cannot compensate latencies anymore, so the latency compensation will be deactivated for all tracks which are involved in this feedback network, regardless if the SEND control is indeed used by you or not. A possible solution is to deactivate the SEND controls on the audio track (right-click on the SEND control and choose "deactivate").

Note that the same problem may occur when you activate the SEND controls on the other return tracks, e.g. activate SEND B on RETURN A and SEND A on RETURN B.

2. There will always be at least 1 sample delay when routing a return track back into an ordinary audio track. This has to do with the computation cycle of the audio engine. Here's a (simplified) explanation: Live basically "scans" each of your tracks from left to right and "collects" each track's audio data, sample by sample. At the very end of each cycle, the master track's audio (or anything that is routed to your soundcard's output) will be sent to the DAC. Then it starts over, calculates the next sample and so forth. Now, if you route audio from a return track back in to an ordinary audio track, this signal will always be delayed, because it falls into the next computation cycle. Thus you will never be able to reach full phase cancellation in such a routing scenario. There is no workaround for this. Note that this really only affects return tracks which are routed back into audio tracks. Routing an audio track into another audio track is no problem, regardless into which direction.

(*) Well, strictly technically spoken, the latency is always there, but in most cases you won't notice it as long as Live compensates it.

Best,
Nico

[Khazul]

For 'sample' in the above, I think read 'sample buffer'.

Also the deferral to the next calculation cycle only occurs for a track in which there is a poss ble feedback loop somewhere in the chain (ie a send directly, or indirectly via other tracks enabled to itself - even if level is -inf), rather than just because a return is routed to an audio track (hence why I allways suggest disabling all sends that you do not explicitly need - in fact i wish live would by default leave all sends disabaled like cubase for eg for this reason).

The deferral latency (I think) depends on the plugin buffer size, which will usually be the audio interface buffer size unless changed in live settings, so high latency on your audio interface may make this worse.

This is at least my observations from testing various scenarios - I guess it would be useful sometime to try to collect all these observations from various people and clarifications from Ableton (thanks [nis]) to try and document them fully.

[sporkles]

I'm not the most technically savvy person here, so forgive my ignorance, but if we see this in light of the recent discussion
on delay compensation and the "Third party plugin FAIL" post:

Why does Artillery 2 seem to be more on time if I put it on a bus track BEFORE the master, routing the return tracks to this
bus, than if I put it directly on the master channel?

[ScottV]

Thanks for the responses.

My scenario is I may have 20-30 tracks, 8-10 Returns. I may send a Return to another Return but I've never had the need to send a Return to another track.

My current work around is to put the output of all of my tracks and Returns to "Ext. Out" (1/2). This seems to work fine up until I reach my mixing/mastering stage. Let me give you a scenario.

I have a couple sub-masters tracks that I've routed various other tracks into. The sub-masters are then routed to their own sub-master that goes out to "Ext. Out" (1/2). I've found that sending audio to the Master causes some type of latency-- whether it's with my send/return's or something else (which is why I have a work around in the first place). Now, I take my Return's and set them to "Ext. Out" (1/2). Everything is on time and I'm a happy camper.

Now, let's say I want to put an EQ on the whole track. Well, that's cool for the normal tracks since I have them routed to a main sub-master that goes out to "Ext. Out" (1/2), but the Return's are going straight out to "Ext. Out" (1/2) without going through any common channel.

So I'm forced to render all of my Return's and make them into normal tracks, route them to the main sub-master, and go on my way. This isn't very efficient and causes major headaches if I want to make changes to the track-- hence my complaint.

I would be fine sending everything to the Master with a latency in the Return's only if the other tracks were compensated to match this delay. Do other hosts have this issue?

[Khazul]

Make sure any return that you do not need at some point in your track is disabled.

If you returns are routed to your sub master for exampole - make sure all sends are disabled on those tracks - EVEN IF AT ZERO!

[Delie]

I'd second khazul - recommend disabling all sends you're not using to avoid the chance of feedback loops.

[Khazul]

I commend ableton for allowing the possibility of feedback loops - sometimes its a really useful creative thing.

But I also wonder if given the number time people get caught out by it (not nescessarily this case, but in general), it is something that should perhaps be locked by default out in preferences under a general 'enable advanced fatures that can get you in a mess' type option

[ScottV]

Unfortunately that's not an option, Khazul. I use 3 dimensional sound in my music which requires layers of reflection and reverb. They're always on. I'd really like to get some help getting things to work right in the first place.

Ableton, any input?

[Khazul]

Yes - but do you have any potential feedback loops by accident (even if the send level is actually zero, for eg Return A -> Track -> Track -> Send A is still a feedback loop)?

[oblique strategies]

Thanks for the info Nico

[chaosmoon]

So basically, if your using external hardware effects units (reverbs, delays etc.) which you would like to record (separately from the master take) at some point; You'll need to do the following:

Put an "External Audio Instrument" on a Return track.
Create an Audio Track (for recording the FX signal) set Monitor to "IN" with "Audio from" the Return track, Post FX
Disable sends on recording Audio Track.