Troubleshooting audio performance problems

The TLDR; take away from this is that leaving record enabled on an instrument/MIDI track can cause extra system load that negatively impacts audio performance. A work around is unchecking the automatic record enable when selecting a track in Cubase preferences.

Another TLDR; take away is that a record enabled instrument/MIDI track that uses an instrument with a long release (delay/reverb/etc) can significantly degrade audio performance and halt audio rendering entirely even with just a few notes being played.

I started using Massive X recently (from Komplete 14) and noticed pretty quick that audio performance went from adequate to miserable on a machine that has been working fine for years. Massive X was the worst instrument of the bunch that I noticed when testing but this extra load when record arming an instrument/MIDI track can be seen with other instruments as well. So while it is a non-Steinberg product involved it would seem that there are implications for Steinberg/Cubase too.

Before discovering that record enable was the main factor I looked at the config settings that forum and internet searches commonly lead to: ASIO guard settings, enable multi-processing, audio device buffer sizes, disabling unused features in the BIOS, video drivers, USB port of the audio interface, and WIFI connections. No combination of these configurations produced the same benefit as turning off record on the Massive X track.

The first screenshot shows the instrument and patch, the record enabled status of the track, the simple MIDI part being looped over, and the audio performance. I circled the release knob in the instrument which is a setting that will be changed in subsequent screenshots. Notice the audio performance load. Changing the interface buffer size, ASIO settings, etc did not have nearly the positive effect on performance as disabling record on the track.

Just by disabling record on the track the audio performance profile changed and improved considerably. ASIO guard is still high but playback was smooth.

With this specific Massive X patch there is considerable reverb/delay/etc that causes the instrument to render audio long after notes have been played. By turning down the release knob on the instrument the ASIO guard performance improved.

Even with the release knob turned all the way down the audio performance takes a negative turn when record has been re-enabled on the track.

Thinking that the performance may have been related to using an instrument track directly I added a MIDI track and moved the parts to it. It didn’t make any noticeable difference.

Below is the most significant screenshot IMO. When turning the release knob to max on the instrument while playing the simple MIDI part my system audio quit rendering and seized up.

The GUI remained responsive though and after turning release back down to zero audio resumed rendering.

With the release knob turned all the way to max on the instrument and with record disabled on the track my system could render the audio. I didn’t grab a screenshot to show this but it confirmed that record being enabled on the track is the single biggest factor for audio performance in my tests.

The workaround I’m using is to uncheck the preference setting that automatically enables recording when a track is selected. With this change I can interact with my project without these crippling audio performance problems popping up unexpectedly.

If anyone knows why record enabling a track causes increased audio usage I’d love to have that explained. Before arriving at these realizations I was looking at new PCs and digging into boilerplate configuration settings. I’m running Windows 10 on a Thinkpad laptop with an i7-6700 Intel processor, 64 GB RAM, 2 Samsung NVMe SSDs, NVidia card. It was top of the line back in 2016 when I bought it and it’s always been rock solid. I’m questioning if even a brand new machine would resolve this issue. Or maybe there is some other settings I missed?

Any help understanding this would be most appreciated. Thanks!

1 Like

If you record enable a track, it is out in the realtime path, which has the buffer size that you set in your audiointerface. That puts more strain ob the CPU because all calculations must happen so that the (smaller) buffer can be filled in time, else there will be dropouts. This is the “peak” value in the performance meter.
All other tracks are processed in the ASIOGuard path, which uses a much higher extra buffer (depending on the setting) to prevent dropouts, at the expense of a higher latency of course.
Record enabled tracks need to have low latency, so they can’t be processed with ASIOGuard.
Depending on the overall CPU usage of your system, record enable can bring the realtime path to a point where it isn’t able to process with sufficient speed and produces dropouts. If that is the case, you can either increase your audio driver buffer or reduce the overall CPU usage of your project by e.g. freezing or rendering tracks.

2 Likes

Thanks @fese for the explanation, it makes perfect sense. I spent a good deal of time searching for answers and found nothing this succinct. If this information is out there it is hiding. Hopefully this saves someone else time and headaches.

What surprises me is that a track only has to be record enabled to be put it into real-time processing, not actually recording. The preference change to not automatically record enable a track when selecting it has helped. Freezing tracks will also help.

There are already threads about which machines people are using to run Cubase so I hate to fragment this thread or be redundant but any tips on which specs matter most for real-time processing are welcome.

Here’s a series of 3 videos that cover latency, ASIO guard, and record enabled tracks. Can’t believe I didn’t arrive at this explanation with as many searches as I did. Apparently the handling of record enabled tracks is widely understood tribal knowledge?

I’m still left wondering how to choose a machine with confidence that it will perform as a DAW. Is my current machine a clunker by Cubase 12 standards? It has been a beast for my day job, hard to believe it would fall short in any way.

In general I think your machine should be fine for playing virtual instruments, although those can put quite some strain on the realtime path (don’t use Massive, so I don’t know about that).
It also depends on how big your overall load on the system is already. VSTi usually get rendered on one single Core, and the more all your cores are already computing something else, the less resources are left for the instrument. Also, the more notes you play, the more cpu usage.
Some synths (e.g. uhe Diva) have an option to enable multithreading for the plugin, that can help.

1 Like

Thanks again @fese. Now that I know the reason for the issue described in my original post I can work around it using existing features in Cubase. Your help was key to filling this gap in my knowledge.