Delay Compensation in an AudioProcessorGraph with internal parallel signal paths

I am making a plugin that uses juce::AudioProcessorGraph. Inside the graph, the audio signal is split into separate paths for processing, which are then summed at the AudioOutputNode.

Example: the Graph’s AudioInputNode connects to both a Compressor Node and an EQ Node, which each connect to the AudioOutputNode. The Compressor introduces 30 samples of latency, while the EQ introduces 10 samples. These latency amounts might change at runtime if the user changes specific settings. The Compressor and EQ both inherit from juce::AudioProcessor, and they set their latencies at initialization/during playback using AudioProcessor::setLatencySamples.

Given the above, will the audio being combined at the AudioOutputNode from the Compressor and EQ will be synchronized correctly, taking into account their different delay amounts? And would this still be the case if one of the processor’s latencies changed at runtime?

Here are some additional threads I found while researching this:

The graph will correctly process the delay times if you set the latency internal to the node prior to the graph being constructed, I can’t remember if this happens automatically, you may need to force a graph reconstruction if one of the setting which changes latency occurs.

What do you mean by ‘prior to the graph being constructed’? Before the graph’s connections are created?

Currently, I am initializing processors in prepareToPlay:
mainProcessor->addNode(std::make_unique<CompressorProc>(args));
This should be setting each processor’s latency internally, since setLatencySamples() is called in each processor’s constructor.

Then later in prepareToPlay I connect the processor nodes as needed with:
mainProcessor->addConnection(...)

How would you recommend doing this? I’m not sure I follow. Thanks!

If you look internal to the graph there is something called a render sequence which includes your nodes as well as latency compensator delay nodes which it injects into connections to correct latency.

Try: triggerAsyncUpdate or checkout topologyChanged() in the graph

2 Likes