Tracktion Engine in a plug-in with 0 latency?

Hi everyone,

The EngineInPluginDemo shows that the plug-in latency should be set equal to the block size. This introduces a latency which makes the plug-in not suitable for real-time recording because a musician wants to monitor the instrument or vocal with the least amount of latency possible.

Is this latency necessary or can it safely be set to 0?

This is the example:

Thank you,

I think since I rewrote the audio engine it should be possible to process without this latency.

@RolandMR wrote the plugin side of the Engine though so maybe there’s a reason it’s still require. Roland, could it be that the audio inputs won’t be dispatched correctly if they’re not fifo’ed? Or the MIDI inputs?

MIDI isn’t required for me at the moment. Let’s wait for his answer.

I’ll need to verify but I think a fixed block size was only required if you were using racks or aux send/return.

According to the documentation it looks like there is no work-around for the latency in a plug-in. I tried to simply remove the setLatencySamples(samplesPerBlock) line but there is defenitely a latency happening (and the DAW will not compensate without that one line).

This is concering to me, because this means the engine is unsuitable for any application where zero latency is desired.

/** If the size of the audio buffer passed to processBlock will be fixed or not.
    If you are creating a plugin, this should be false, and your plguin will have
    one block of latency. If you are handling the audio device callback yourself,
    this can be true. */
bool fixedBlockSize = false;

From tracktion_engine/tracktion_HostedAudioDevice.h at master · Tracktion/tracktion_engine · GitHub

Right, but what we’re discussing is whether that is a legacy option and if now, with the new audio engine fixedBlockSize can be used as true in a plugin and no latency will be required.

You can try it out with the EngineInPlugin demo or your own code by passing that parameter as true.

We just need to determine if we can remove it all together.

Without even testing it, I already can guess this assert will be triggered when fixedBlockSize equals true and a DAW decides to sends small chunks of buffers:

void HostedAudioDeviceInterface::processBlock (juce::AudioBuffer<float>& buffer, juce::MidiBuffer& midi)
    if (parameters.fixedBlockSize)
        jassert (buffer.getNumSamples() == parameters.blockSize);

And if you comment that out?

I haven’t attached a debugger (because it requires me to disable SIP), but first quick test in Logic is promising because it sounds fine and the latency is gone. And I actually think Logic is chunking because as far as I can remember from tests in the past, Logic always prepares the plug-in with a fixed (1024?) block size.

Is it possible this fix can be pushed to dev?

1 Like

Thank you Dave, amazing! I already tried it yesterday and works.

Related to that commit, I wondered why you decided to remove the root CMakeList.txt file because it broke my own CMake setup. FetchContent_MakeAvailable(Tracktion) in my CMake didn’t work anymore and I had to add add_subdirectory(${tracktion_SOURCE_DIR}/modules) to make it work.

Sorry, I thought that was just building the examples but didn’t work properly.
I’ve added back the relevant bit now so it should work for you again?

One question related to that though, if you were using FetchContent_MakeAvailable(Tracktion), where is CMake picking up “Tracktion” from?

Thank you.
I’m using FetchContent_Declare to pull the repo and FetchContent_MakeAvailable will look for the root CMakeLists.txt, similar to when you add any sub directory.

Now that we talk about all this CMake stuff, I also wondered if I could simplify my script because currently I am pulling Tracktion as well as JUCE to fix a CMake error from tracktion repo "Unknown CMake command “juce_add_modules”. Do you have any recommendations to setup CMake, does it make sense to pull both? At this moment I am pulling the exact same JUCE version as tracktion is using which feels a bit silly and error prone.