DAW performance and how you route audio through groups

Cubase
1

Here is an excellent in-layman’s-terms explanation about how it happens that your CPU load might be only at 40%, but your Cubase Performance meter is topping out to the red.

CPU Performance vs. Real-Time Performance in Digital Audio Workstations (DAW) - YouTube

Thanks, Steve, for posting. That is a great explanation of CPU vs. Real-time performance!

Here’s another angle that I’ve discovered in my Cubase travels. The DAW performance can have a lot to do with how you route audio through groups. After watching some informative mixing videos, years ago, I developed a template for mixing that had me using a lot of groups to submix. Imagine Top and Bottom Snare going to a SNARE group, which then feeds a DRUMS group, which then feeds perhaps an ALL MUSIC group. Let your imagination go wild here. This kind of templating made a lot of sense to me in a workflow context - I could work with the SNARE bus, the DRUMS bus, etc. What didn’t occur to me at the time was that I was forcing Cubase to compromise on multi-threading. Any processing (plugins) taking place on my Top Snare track has to finish before any processing (summing and plugins) on my SNARE group, which then feeds into the subsequent groups (more summing, more plugins). Imagine how difficult it can get for Cubase to finish all the required processing, up to my MASTER buss, to feed audio into the audio buffer, if my audio routing is more serial than parallel?

I started having projects max out on the performance meter, and read a lot of threads on DAW performance vs. CPU cores, before realizing that I had some ability to fix my own problem. By cutting down on the “length” of my audio routing (fewer serial paths through groups) and instead using a more parallel audio routing, I found that Cubase was much more able to utilize the multiple CPU cores (parallel processing ability) and get the job done within each audio buffer.

Using VCA faders rather than Groups is a great compromise in this situation. If you don’t need plugin processing on your SNARE group, for example, use a VCA fader instead to avoid a level of unnecessary summing.

By organizing my audio routing in a new way, I was actually able to use far MORE plugins than before, without taxing the real-time processing. It didn’t make logical sense at first, but I found that, for example, I could put the same plugins on every drum track that I used to put on the single DRUMS group, with less strain on performance. Sure, this is an extreme example, and who wants to duplicate to that extent, but if you’re stuck for performance, give it a try.

Allister

1 Like
2

Nice find, have to try this myself.

However, my signal flow is very extensive on groups into groups into groups and it is so for a reason. My cpu idles around 30 % while the vst performance is around 90 %. I believe there must be something that can be done to improve that ratio. Something that doesn’t limit or dictate workflow. Something like enabling Cubase to process the different plugins on a channel on different cores. Of course I have no real idea of what’s going on under the hood, how complicated it could be etc. This is just from a user perspective.

3

This is actually great news, it means that if your experiencing crackles in real time play back, you most likely won’t have them in your final mix-down. Good to know…

I was also wondering in the past, why my system lays down the mix on my hard-drive a lot faster then playback. Now I know. Great video, thanks for sharing.

4

This will only be possible if cubase renders everything way in advance. So all tracks are pre rendered and played from a buffer. Like DOP but then for the whole project. Only the mixing will be real time, so groups don’t have to wait till the sources are ready. But if you change anything in the project, a part has to be re rendered. Only live inputs will be realtime then.
If you want to understand the advantage, think like this: If you play the project it takes a certain amount of CPU. If you render it the same amount. But if you then play it again, the second time will take no cpu since it is already rendered. This unused cpu is the available for new renders. You would need a good CPU and especially lots of ram or renders could be on an ssd.

5

So like putting saturation, distortion, reverb, etc. on individual tracks rather than group tracks, if it concerns multiple tracks with same effects on the signal chain? I´m not sure I quite undertood this organizing thing. Flowchart would be nice for stupid people like myself :slight_smile:

6

Jari, my understanding (and I’m inviting correction from anyone more familiar with Cubase multi-thread programming) is that Cubase is better able to use your computer’s multi-threading ability - that is, processing across the multiple cores of your CPU - if you take a more parallel approach in routing your tracks through groups and into the master buss.

This means that Cubase can potentially get more done - more plugins, more VSTi playback, etc. - if we use fewer groups that feed into other groups, and into other groups, and on and on.

Yes, it can make an incredible amount of sense to group tracks, in terms of workflow, but especially if you’re seeing your real-time processing struggling to keep up with your project, consider using fewer group channels. Rather than, for example, routing strings to groups of CELLOS, VIOLINS, etc. and then into a group called STRINGS, which then routes to a group called ALL MUSIC - consider dropping the CELLOS/VIOLINS groups and routing the individual strings tracks into the STRINGS group. One fewer level of summing and plugin processing, combined with the removed dependency from the group to wait for completion of individual track processing, should give Cubase a greater ability to engage multiple threads, and finish all the computations within the length of your audio buffer. And while it may seem that it would use less processing power to put plugins on the group channels than across the individual tracks, it absolutely has an impact on Cubase’s ability to utilize multi-threading in the best way.

My point is that I noticed an opportunity to change my workflow to get more out of my hardware, rather than having to upgrade my hardware!

Allister

7

One way to accomplish this is to Freeze Channel - which will render the plugins on that channel and then disable them (saving processing). Even if you only need to do that temporarily, say, to record new tracks, you can then Unfreeze the channel(s) and tweak the settings on your plugins!

8

Great thread! I am battling for some time now with the concept of groups of groups of groups.
One of the reasons to work that way - besides processing - was also to be able to bounce whatever I needed on terms of groups of instruments.
I figured out that for this particular aspect I can create outputs and not groups, which gives me minus one layer in the workflow.

I am also using a group to reunite all the tracks in order to apply a master processing. Wouldn’t it be cool to figure out a way not to use a group for that purpose?

1 Like