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?
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?
Sorry for the late reply, I spend a couple of hours today testing this and trying to figure this out.
I think there were actually a couple of things happening that pointed us to the wrong things:
Our beta tester did not have the system performance set to performance mode.
On my own test I found today that when I switched the clock from my audio device to internal instead of an external AD/DA all of a sudden Cubase Reaper and Waveform performed more or less equal.
The only thing that I don’t fully understand yet is why Cubase and Reaper seemed to have less problems with the externally clocked device. But I guess that’s not really a problem…
In the meantime we did seem to find some bugs in Waveform while testing it with a focusrite scarlet. This is the report from my colleague:
Running the built-in 4OSC plugin on the master works fine for everything I tested
buffer sizes between 16 and 256
sample rates 44.1k and 48k
“Use Realtime priority mode” On and Off
“CPU cores to use” 1, 16
When switching sample rates while playing (on the asio driver control panel, but not in the waveform settings gui) Waveform becomes unresponsive for several seconds, then the playhead and timecode advances several times faster than normal and there is no sound. I had to close restart the application to get it working again.
Rapidly changing the “number of CPU cores to use” in the settings by dragging the slider crashes the application if an Edit is open (either playing or not).
