Aux send introduces delay

[dRowAudio]

I think this is missing the problem with latency that we currently have.

The problem is due to the fact that we deal with latency by virtually moving the playhead forwards in time for each track by the amount of latency introduced by the plugin chain. This means for example that the samples read are a bit in the future, once they have passed through the plugins, they get delayed by this amount and end up back in sync with the master playhead time.

Separately, plugins that rely on other tracks (Racks, aux receives, track input devices etc.) work by keeping the last block of audio that passed through them, then sharing this with the receive pairs on each process block. This double buffering is required because, due to multithreading, tracks can be processed in any order (i.e. a track which is receiving audio can be processed before the sending track). Because the receive end of these plugins are receiving a block of audio from the last process block, they also need to impart a one block latency for the current block to match up with the received audio.

This all works fine if the number of sends per track is limited to one.
The problems arise when there are multiple sends because then this double-buffering technique doesn't work, the most latency introduced will be a single block which now isn't correct. Further to this, because the order of track processing isn't deterministic, receives may get blocks from several iterations in the past if they've passed through several send/receive blocks.


The solution is two fold. Firstly we need to calculate the maximum latency for all the tracks and then apply this to all tracks (minus the latency they themselves introduce) so they all align. This has the additional negative impact that all tracks will now include the latency, not just those that introduce it.

However, if we do this, we still need to deal with the case where tracks are sending to each other, this means a fundamental reworking of the audio graph and making sure that items needing to send audio are processed before those needing to receive it.

I can't overstate the size and complexity of this task. If anyone has ever dealt with cyclic graphs with shared data in a multi-threaded environment they'll know what I mean. This is on our radar but is several months worth of work and testing and obviously can't be dropped in to place just before a major launch!

The fact that it also affects only a minority of sessions has kept it fairly low priority. It can usually be worked around by a few small tweaks in signal flow. Sorry if that's not the best news but it really isn't as simple as is being suggested in this thread!

[Steve Bolivar]

I hate to say it but this is probably something that should be put in a side note in the manual since it will prevent some problems down the road for some users. Include workarounds like duplicating tracks and using racks.

It kinda sucks because some people will see this and freak the F@#$& out, when in reality it can be worked around and doesn't come up all that often.

[Mr Coffeehouse]

How is this for a straightforward workaround -?
Please let me know if you think it will work..
I haven't tested this but will later.

Let's say I want 4 different reverbs sends on a vocal track (sends 1 thru 4).

Instead of placing all 4 sends on that track, which will create delay problems, I..

- Create 3 copies of the vocal track, making 4 identical tracks total.
- Mute the 3 copies by using a volume filter set to off on each, but not the original.
(Make sure to place the volume filter last on the chain of VSTs.)
- Place Send 1 on the original.
- Place send 2 on the 1st copy, at some location before the muted volume.
- Place send 3 on the 2nd copy, at some location before the muted volume.
- Place send 4 on the 3rd copy, at some location before the muted volume.

Thanks, Michael at The Coffeehouse

[dRowAudio]

Yes, or you could use a Rack with containing your three reverbs and three stereo outputs.
Then you could use a set of inputs for each track to control where the input is sent to (in this case, the vocal track would send to inputs 1 & 2 and these would be wired to each reverb).

You could then put the Rack on every track you want to send to the reverbs and use the input level to adjust the amount of send (just send it to a new set of inputs).

You then might also want to create some tracks that are the output of these Racks and simply bypass them on the original.

Just another way of doing it without duplicating the track.

[HansP]

What if one of the reverbs has remarkable latency?