Glitches on low latency - Tracktion Engine

Hey there,

We are currently testing how low we can go. What we do is load the Moscillator from melda (MOscillator | MeldaProduction - it’s free) on the master in a default project in Reaper, Cubase, Waveform and the app we create.
We make sure that Reaper and Cubase have all buffering options disabled.

Now the issue is that when we go below 128 samples, it creates no issues at all in Cubase and Reaper, but in Waveform and our app it glitches a lot, to the point where it sounds like a ringmodulator.

At the same time, we are noticing that a lot of people are trying 64 and even 32 sample latencies for live use of applications. But Tracktion Engine seems to be causing issues at those latencies. Wat could be the issue here?

*Edit this is on Windows 11

What branch is this using?

And is this with single of multi-threaded rendering?

I’m testing in waveform 13.044 and 12.1.8. These are the settings:

The commit we are currently using for our own app is this one: 746b7c95f7

Indeed multicore processing has been turned on in all programs we test with.

I’ve been doing a fair but of optimisation on our feature/launcher technical preview branch which is what we’re using in W13.

First things first would be to enable the “Enable shared playback memory” option. That should reduce cache pressure.

But can I get this right that you’re just creating loads of plugins in the main FX bus? This will give a basically serial playback graph (as those can’t be processed in parallel for obvious reasons). So you might actually get better performance from using single-threaded processing. There is overhead in having those 32-threads running but not doing much.

One other thing is that we have a new CPU meter in W13, open that by clicking on the CPU meter in the top right. What does the graph look like? Is it spiky or just full?

Also, by chance, Jules did a podcast the other week where exactly these kinds of things were discussed. It’s well worth a listen as they discuss things that can affect performance on modern CPUs. The TL;DR is that you need a real-world use case, profile it and then optimise based on that:

Hi Dave, thanks for the help. I dont think I can find that “Enable shared playback memory” in the waveform settings. Or is that purely a tracktion engine setting?

In any case, I tried to get to the minimum project that showed the different between waveform and reaper/cubase. In the project that I suggest to recreate I actually only load 1 instance of the tone generator on the master channel.
In our own app we also tried another tone generator with the same result.

So I don’t think this is a muticore / singlecore issue. I can send you a project file if you like?

btw, the CPU meter while the sound is breaking up:
image

No, click on that icon and you’ll get a much better view.

It’s in the middle of the screenshot you’ve shown above. The second red option.

Do you see the same thing with the JUCE plugin host example app?
I’m just wondering if it’s a driver or audio device handling kind of issue?