Performance: no hybrid buffering? And plans to add that in the future?

[jens]

That's weird - I've haven't seen anything like this before - according to Tracktion's own CPU meter a few plugins eat up my CPU up alomst entirely and there playback artifacts start happening.

Windows task-manager shows too much for what I am doing, but not nearly as much. What does the "CPU Usage" window report anyway? What's 100% - all cores or the first core?

Does anyone else experience excessive CPU consumption/terribly bad performance with Tracktion?


Edit: yes, whether I set Tracktion to 1 or to 20 cores doesn't seem to make any difference at all.

[jens]

Oh, for some reason it was set to the shortest possible ASIO-latency (8 samples - I certainly didn't do that) and now @128 it's seems to be a bit better - still excessive though.

[UnionS8]

The DAW CPU load is different from the CPU overall load. There are many articles on it over the internet. Although you have several cores, the audio rendering is still more linear than parallel. Even though your computer has plenty of power in parallel, it falls short in the linear matter. This is one of the reasons, we don't see many GPU plugins. Although the GPU cards are so powerfull (much more than CPU in their own way), their strength is in the parallel processing. AI could benefit from it in the future.

[Teksonik]

I've been very impressed with WF's CPU usage so far. Of course coming from FL Studio it's not hard to out perform it in regards to CPU demand. FL's meter shows percentage of audio buffer in use so it's not an actual CPU meter and that makes a 1:1 comparison with WF's meter impossible. For example a patch that shows 24% on FL's meter shows 4% on WF's

I find WF's meter to be in near lock step with Windows' Task Manager CPU read out. Within a percentage point one way or the other (of course as long as you're not running any other software at the time and we really shouldn't while using any DAW).

My studio system is an ageing i7 8700k so certainly not state of the art these days but I've never had to freeze in any DAW so upgrading it is not a high priority at this time.

[jens]

Yeah, I made some tests and Tracktion's performance is really rather abysmal unfortunately.

[jens]

The DAW CPU load is different from the CPU overall load.

Yes, I know - which is why over the decades I got quite used to always checking both.

[Teksonik]

Yeah, I made some tests and Tracktion's performance is really rather abysmal unfortunately.

In what use case? Certain plugins, audio recording or ? Like I said I've been impressed by the CPU demand so far. Perhaps there are system differences or differences in usage to explain our varying opinions on demand.

Do you work at high sample rates ? I'm working at 44.1k now and occasionally 48k with a buffer of 512 and sometimes 256 samples. I'm on Windows 10.

As I said my studio system is far from state of the art these days but I don't see any indication that WF13 will give me any issues with CPU demand for the way I work.

It's kind of hard to see but WF's meter is in perfect lock step with Window's Task Manager performance meter. 5% for one instance each of Speedrum, Avenger 2, and Spire, and two instances of DUNE 3 all playing at the same time is very acceptable to me. My CPU isn't even at full turbo speed of 4.7 GHz so I consider those results to be pretty impressive and tells me I have a ton of headroom left.

WF CPU 040324-2.png

[jens]

Yeah, I made some tests and Tracktion's performance is really rather abysmal unfortunately.

In what use case? Certain plugins, audio recording or ?

Like I said I've been impressed by the CPU demand so far. Perhaps there are system differences or differences in usage to explain our varying opinions on demand.

Do you work at high sample rates ? I'm working at 44.1k now and occasionally 48k with a buffer of 512 and sometimes 256 samples. I'm on Windows 10.

I was talking about using plugins - but that includes audio-streaming too.

As I said my studio system is far from state of the art these days but I don't see any indication that WF13 will give me any issues with CPU demand for the way I work.

But is that a gut feeling or did you make any systematic testing?

[Teksonik]

Well I've done real world testing for the way I work as what else really matters? I haven't tried to "break" it with testing designed to do just that. If it's efficient with the plugins I use and the workflow I employ on a daily basis then that's all that matters to me.

So it's not a gut feeling, it's based on the test results I've gotten so far. Trust me, if there were any issues I would report them in a heartbeat it's just that I can't find anything to complain about so far in regards to CPU demand.

I'm not trying to say you're not having issues only that I'm not having any here at this point.

I'm not that invested in WF in both time and money that I couldn't just walk away given a reason to do so but at this point I simply don't have such a reason.

[jens]

I think I now have sussed out what the problem is:

Tracktion simply doesn't have a hybrid engine - if I switch off Studio One's hybrid engine it even performs slightly worse than Tracktion.

[jens]

I now changed the thread title.

[bk]

I think I now have sussed out what the problem is:

Tracktion simply doesn't have a hybrid engine

OK. I'll bite. What the heck is a hybrid engine?

[bk]

I think I now have sussed out what the problem is:

Tracktion simply doesn't have a hybrid engine

OK. I'll bite. What the heck is a hybrid engine?

OK, some poking around the internet shows hybrid audio engine as running some tracks high latency while running others at low latency.
Would it be somewhat equivalent to using a few well placed freeze point plugs in Waveform?

[jens]

It's not universally called "hybrid engine", but I think it's the most adequate term.


Here's how Samplitude's manual explains it:

In the Audio Engine, the core of every DAW, mixes the audio data that is present at the inputs and played back from the hard disk, calculates the effects that go with it, and outputs the result via the outputs. The processing takes place block by block: The data is read in small portions into a memory area (buffer), calculations are performed with the data of the buffer and transferred to other buffers, which are then provided to the sound card for output. While one buffer is being filled with new input data, another buffer is being summed with another, effects calculations are taking place on yet another buffer, another buffer is being copied to an output buffer, another output buffer is being read by the sound card for playback. These read, write and compute processes must be synchronized, because if one sub-function cannot provide its results to the next in time, there will be dropouts in recording or playback. In this context, the size of the buffers has a significant influence on the behavior of the audio engine: Large buffers are less sensitive to short load peaks in the system, because the copy operations between the buffers occur less frequently and the parts of the processing chain have more time to catch up with the delays they create. The disadvantage of large buffers is that the engine can respond to changes in parameters by the user (e.g. the volume on a mixer channel or an effect parameter) with a greater delay (latency), since these changes can only take effect with the next buffer.

Samplitude uses the Hybrid Audio Engine by default. This engine combines two different engines with each other (hence "hybrid"): For real-time functions like monitoring, i.e. the immediate playback of the received audio signal with effects, and for the playback of software instruments played live via MIDI, a low-latency engine with low delay (latency ) and small buffers (ASIO buffer size of the sound card) is used. For the playback of recorded audio data, a second engine (Economy Engine) can be used, which works with much larger buffers (VIP object buffers) and is resource-saving and allows the integration of computationally intensive effects.

The Hybrid Engine thus enables a combination of Low Latency Engine and Economy Engine for track and effect calculation. For example, you can play back many CPU-intensive VST instruments in so-called "Economy" tracks (see below), while only the VST instrument that you are currently playing live is calculated in the Low Latency Engine.

And here's a bit from Studio One's manual:

When you are working with a large amount of audio tracks and virtual instruments, computer performance can limit your capabilities. You can increase the amount of buffer to help free up computer resources, but this traditionally comes at the cost of greater latency (or delay) when monitoring audio inputs or playing virtual instruments. Set the buffer too low, and audio dropouts and glitches can occur.

To remedy this, Studio One features Audio Dropout Protection and an advanced Native Low-Latency Monitoring system. Under this system, the tasks of audio playback and monitoring of audio inputs and virtual instruments are handled as separate processes. This, in effect, lets you use a large processing buffer to handle heavy audio playback and effects processing tasks, while keeping latency low for audio input and virtual instrument monitoring.

The latency that you hear when monitoring audio inputs or playing virtual instruments is based primarily on the Device Block Size that you specify in the Studio One/Options/Audio Setup/Audio Device (macOS: Preferences/Audio Setup/Audio Device) window. For the lowest latency, Device Block Size should be set to the lowest setting that provides the performance you need.

The Audio Dropout Protection system uses its own buffer for playback and processing of audio tracks, distinct from the Device Block Size setting. The size of this buffer (also known as the Process Block Size) depends on the Dropout Protection level that you specify in the Studio One/Options/Audio Setup/Processing (macOS: Preferences/Audio Setup/Processing) window. If you use Native or Hardware Low-Latency Monitoring, the Dropout Protection level has no effect on audible latency, though higher levels can affect the responsiveness of onscreen meters and displays.

As long as the Process Block Size is larger than the Device Block Size you've specified, you have the option to use Native Low-Latency Monitoring.

And Cubase's manual:

The ASIO-Guard allows you to shift as much processing as possible from the ASIO real time path
to the ASIO-Guard processing path. This results in a more stable system.
The ASIO-Guard allows you to preprocess all channels as well as VST instruments that do not
need to be calculated in real time. This leads to fewer dropouts, the ability to process more tracks
or plug-ins, and the ability to use smaller buffer sizes.

High ASIO-Guard levels lead to an increased ASIO-Guard latency. When you adjust a volume
fader, for example, you will hear the parameter changes with a slight delay. The ASIO-Guard
latency, in contrast to the latency of the audio hardware, is independent from live input.

If you activate the monitoring for an input channel, a MIDI instrument, or a VST instrument
channel, the audio channel and all dependent channels are automatically switched from ASIOGuard to real time processing and vice versa. This results in a gentle fade out and fade in of the
audio channel.

Most DAWs have this nowadays. At the cost of a slightly less responsive application you can use roughly twice as many plugins as without with low input latencies.

[UnionS8]

I've been using Cubase for years, and I discovered the ASIO Guard literally few days ago. It's a miracle. Now I wish, we could get something like this in Waveform. But I doubt, it would be possible in the near future because of the complex routing possibilities within Waveform. But I always felt, Waveform is lighter on CPU than Cubase (without the ASIO Guard). Furthermore: Waveform has those unique freeze points, which are also a miracle