[SOLVED] - Audio Dropouts on Cubase 13 With macOS 15.6.1 Sequoia (w/ 60% Idle CPU)

EDIT: Solved it with a very simple action - removing plugins from the Stereo Out - which was difficult to identify since there was no clear indication of the culprit.

Hi Steinberg,

I’m having audio dropouts in my setup which is officially supported.

This is my Mac (2TB SSD):

This is my Cubase:

In Cubase, while trying to listen to the playback, I encounter the following behavior:

The Meters are running as expected, showcasing audio levels until suddenly they they all black out for a few moments and they they return.. (Probably for each round 2058 samples) and the cursor goes forward but no it’s like a few miliseconds of audio are coming through after a little bit.

To clarify - during this time, the meters does not reflect the actual audio that comes out.

The buffer size is maxed out:

Here is the Activity Monitor while there playback from Cubase is running (while audio doesn’t come out but in little quick transients.

You can see that there are over 50% available for the machine’s processing power.

The computer is connected to a Motu MK5 Ultralite directly via USB C, and has a thunderbolt conncetion to a USB HUB from Dell, that’s connected to a Monitor by Dell.

Previously, I disconnected the hub from the computer and it solved the issue.

Now, even with nothing connected to the computer, this behavior proceeds.

Currently, I can not work.

Is there a way that Mac limits Cubase to only use up to x amount of CPU?

Is there a way to enable CUBASE consume more CPU?

Is it something else?

Is it a known issue?

Please advise.

Thank you.

I have also tried using the computer with the build in speakers, disconnected from any external device - same issue

ASIO-Guard is activated and Audio Perormance reaches the peak

ASIO-Guard is the only meter that moves here sometimes touches the red sometime doesnt move

Except for contrived benchmark cases, you can never use all the cpu. The amount of the cpu that you can use depends on the details of a particular project you’re working on, for example plugins in use and signal routing.

Hi Glenn, Thanks for your answer.

Is there a way to test and understand where exactly is the bottleneck?

For some context, it’s a project with 116 track (including group and fx tracks), with routing of a few layers for specific channels (e.g. snare top > snare > snare master > snare & kick > drums > master).

Yesterday I have been mixing the track flawlessly for about and hour and a half.

Then, I wanted to test something on the Bass master track - finding a spot in the low frequencies where I could cut to get a more defined sound.

Went for it using Frequency by Steinberg - and ever since the audio dropouts wouldn’t stop and the project is no longer usable.

Even when I try to solo just one track (e.g. the bass and leave all drums, guitars, vocal behind) it wouldn’t work, even though this might be an expected behabior.

How can I troubleshoot this? Sadly I couldn’t find any information on Steinberg.net and all of my Google searches led me to posts similar to mine.

[SOLVED]:

Just solved it after completely removing a few bypassed plugins from the Stereo Out insert chain.

I wish Cubase would provide a clearer indication when a processing path exceeds what the current buffer size can realistically handle and is therefore causing dropouts — for example, explicitly pointing out that the Stereo Out is the bottleneck.

In this case, I essentially arrived at the solution by trial and error. I’d really like to better understand the underlying constraints involved, rather than defaulting to a mindset of “audio dropouts → remove plugins and hope for the best.”

For the best of my knowledge, it’s not about using more CPU - it’s enought that one core from the processor will fail to process the audio to cause a complete failure. If this is the case, I wish Steinberg would have a more transparent indication of the audio processing hapenning in the DAW.

If anyone reading this has tips on where to find this kind of diagnostic information, or how to approach these situations more methodically in Cubase, I’d genuinely appreciate the guidance.

1 Like

It’s not specifically the stereo out that is the bottleneck, it’s that all plugs that are loaded in series will always load a single core more heavily to do the serial processing….so you get a build up from track through buses into the stereo master….so if you use some heavy processing on buses and the master then that’s always going to be perceived as your bottleneck, even if it’s really a combination of what comes before along with the master process.

Offloading those master bus plugs to audiogridder would allow you to run the project with all of the plugs live though it adds some latency so maybe only worth it for final mix stage.

I’m in a final mixing stage.

Tell me more about audiogridder man, I’ll look it up.

There was a thread recently about tools Steinberg could provide to help identify the bottlenecks. The problem is this is a complicated subject. You’ll see many threads where people are confounded when they get audio dropouts due to cpu overload when their system cpu meter shows plenty of cpu available. It’s challenging enough for people to understand why that happens, let alone to make sense of diagnostic tools.

Your case was relatively simple and something like what Reaper does to show the cpu of tracks could help to identify heavy plugins that are causing the problem.

Other cases where the issue is related to routing and grouping of signal paths into threads are more complicated though and would require more complex diagnostic tools.

It’s hard to say if the proposed tools would help by assisting with troubleshooting, or if they would hurt by making a complex subject even more confusing.

1 Like

Or if the processor overhead required to identify and report on thread/CPU utilization itself would simply compound the issue in the first place.

Also, the APM already has a “position and related tracks” feature with “suggested operations” to help identify overloads on a per-track basis, so that may help. I never encounter these issues on my rigs, so I can’t speak to the efficacy of attribution, but the feature itself exists today.

1 Like

Install it run the server application it scans your plugs, then you load AG vst in Cubase and choose your plugs inside of it. It will tend to process on a core that’s not already loaded giving a lot of extra headroom but as said with added latency and of course the insert slot shows as audiogridder loaded so you can’t see what actual plug is loaded in which insert slot without opening it. There’s loads of info online but it’s a pretty simple setup and it’s useable for free. (donationware)

And don’t be thrown by the network/remote computer info…..it works well even installed on the same computer.

I get what you say Glenn! This is true.

And @Grim -

And the AudioGridder project is amazing!!! Thank’s for the introduction!

With all that, I consider a best pratice of a top notch DAW not to leave users in the fog. At least some message with an indication of what is happening.

Instead of switching to poor functionality, and then to scray irreversable messages (already got your project has too many open files, cannot be saved, also project curropted, quit a few).

Well, this motivates me to learn C++! I am also a python developer so that brings some motivation.

Just read your second comment man.

That’s amazing for both making idle computers function as servers or for the computer itself. I’m already a user and have sent a LinkedIn PM to the founder.

I love the fact it’s also introducted with rack shapes.

and BTW @GlennO - it is possible to show the Channel Latency on the Mixer window after enabling it. Helped me TONS right now.

I found out the same - even plugins in the control room inserts can cause surprising latency and weirdness.

If this happens to you, just remove any inserts in any of the control room or output channels.

Yes, that’s right. Are you having a problem with latency?

Not having a problem with latency, but as far as I understand more latency = more CPU usage, and in cases like these where Cubase chokes, I found that removing the plugins with most latency assists the issue. I

No, latency does not equate to cpu load. If removing plugins with high latency solved your problem, that was just a coincidence :grinning_face: .