So I haven’t fully tested this but recently a colleague wrote me that he increased his buffer time in the studio setup panel right before he was doing an export and he had faster render times. Is there any logic to that?
I tried it myself, opened a big orchestral project and increased my buffer to 2048 - and indeed the render was a whole 30 seconds quicker!
Since we are both Mac, we had this tested on another Windows system with an i9 CPU and the result was similar.
My only explanation would be that since the buffer is larger, Cubase simply pre-loads more rendered material into the render buffer which gives it a head start?
Nevertheless, why would Cubase not do this automatically before every render?
Since I am still inconclusive what the reason for this could be and the use of it - I’d be happy to hear your thoughts on this including some render times. Please test this 2 times, one render with Buffer on 256 and second render on 1024/2048 (whatever is highest on your system).
I’ve tried to figure out the export time problem with Cubase, but I can’t make any sense of it. It was fine before version 11, but the render times have been excessively long since then.
Anyway, I tried 64 and 1024. It was slightly faster at 1024, but still about the same as real time, which of course should not be happening for a project with around 50% cpu utilization.
You can watch a cpu meter during the render and cpu is under utilized, which shouldn’t be. I don’t know the cause but other DAWs don’t have this problem.
I suspect there was an export bug at one point and the quick way to fix it was to do exports in nearly real time, and that change has remained since then.
I believe what you’re seeing there is a bug in Cubase.
You have asio guard turned on. That means the buffer size shouldn’t have any effect on performance during the export. The problem is asio guard is being turned off by cubase during the export for some reason.
Maybe somebody from Steinberg can comment on why asio guard is being turned off, but that’s not how other DAWs work, and that may be one reason why exports are slower in Cubase compared to other DAWs.
I actually have better results (live and during rendering) when Asio Guard is turned off. Apple M1 doesn’t seem to work really well with it but it doesn’t matter anyway because AsioGuard originally was just a “hack” for slower computers with poor latency and small buffer memory. With ARM on the rise, this function might become obsolete at some point
ASIO guard is an important feature and almost all DAWs these days have a similar feature to maximize performance. I’d be surprised if you have a project where turning ASIO guard off improves performance, but I suppose that’s possible if you’re comparing a large buffer size to ASIO guard set to low.
Anyway, the issue here is: should Cubase be automatically be turning off ASIO guard during a render? It’s a complicated subject when it comes to parameter automation, but I’d be curious to hear Steinberg’s rationale for the behavior in Cubase.
I have to turn AsioGuard off at all times because it just produces audio glitches and latency - not sure why it behaves this way on M1 Macs before Cubase was M1 optimized, it was advised to keep it off because it could even cause crashes. But anyway, I think it is besides the point. The actual culprit is the buffer size, not Asio Guard - two different things.
Cubase should increase buffer size to the max possible value with every export automatically.
Messing with AsioGuard on export could cause some serious harm, honestly - I wouldn’t want that.
What you’re asking for is basically equivalent to requesting that Steinberg leave ASIO guard turned on during an export. If Cubase did that, you’d always see the better performance you observed with the larger buffer size, regardless of what your audio buffer size is set to in your Studio Setup.
In other words, if Cubase respected the ASIO guard setting during a render, you’d get the benefit you want without the need for you or Steinberg to adjust the buffer size when doing an export (and an adjustment like that can cause problems with parameter automation). As I mentioned above, that’s how other DAWs work.
As for problems with ASIO guard on an AS cpu, that’s news to me. I have a fair bit of experience with M1, M2, and M3 macs running Cubase both native and Rosetta, but I don’t recall ever seeing or hearing of a problem with ASIO guard. In any case, I’m pretty sure there’s no such problem in C13, so it’s almost always a good idea to turn it on, even if it’s only set to “Low”.
I was never talking about Asio Guard at any point in my initial post. I am not using it. All my tests focussed on the audio buffer size only, which is set in the audio configuration dialog under whichever audio interface you’re using. the dialog can look differently depending on what interface and/or driver you are using.
I did turn on AsioGuard last week while I was testing and it was pure mayem. constant glitches. I am using a Mac Studio Ultra with RME Fireface UCX II.
Results may be different on what configuration you’re using.
Also, I think you are misunderstanding how the AsioGuard works. It is a secondary buffer that is meant to assist the playback in your DAW for lower latency and less processing on your plugins. Imagine it being like a band machine running in the background on a looped tape - for every single of your channel there is a single such band machine and it pre-records your parts in the background. But it does not impact your render times - at least not as significantly as what we tested with the primary buffer.
I’m not disagreeing with you . I was just replying to DanielAyo to point out that I believe the reason he saw differing export times at different buffer sizes is because of what I would consider a bug in Cubase. Other DAWs do not have that behavior.
I am extremely familiar with how ASIO guard works .
Sure, bugs are often in the eye of the beholder. Maybe Steinberg has a valid explanation for this behavior and it’s not a bug. However, I would argue it’s a bug for a couple of reasons:
It makes the export behave differently than the project playback. That’s always a bad thing.
It makes renders slower.
Other DAWs don’t do this. When others are doing something different than you, you have to ask yourself if maybe they know something you don’t .
Again, this has been discussed at length over the decades in this forum, the previous forum, etc.
But to address your points–
I don’t understand your #1. If you want playback and rendering to feel identical, wouldn’t you just export in real time? And what is different? Do you know something about the rendering process that the rest of us don’t?
One might argue exactly the opposite-- that it gives you the option to render faster.
Thank goodness. we’re given the option to speed things up faster than just about every other DAW I’ve used. Being able to speed up the render when using UAD plugins by opening up the buffer to its highest value has saved me hours over the years. Faster than Logic, Alsihad and Performer in my experience.
I think it’s pretty common knowledge the buffer sizes are different during the export compared to when you’re doing playback (when ASIO guard is turned on.)
I would humbly disagree that you’re given an option to speed up the export though. I would put it this way: the export is being slowed down and you’re given an option to undo that slowdown
Ditto. There are a lot of factors here and no one workflow is right for everybody. I’m just curious why Steinberg made this decision that slows down the export when there doesn’t seem to be any compensating benefit.
My last word (seriously.!) on this is that it simply and quantitatively does not do that. Support for this perspective is available on this forum in older posts, some of them including comments from Steinberg. This is not new.–and for the life of me, this is the first time I’ve ever heard of the ability to change render speed for the faster referred to as a bug.
Or… use a stopwatch if wondering about other DAWs’ render speeds. Maybe things have changed since the last time I checked, but Cubendo’s been ahead of the pack for the 30+ years I’ve made a living with it, and the option to open the buffer to levels that make editing inconvenient but doubles or triples the rendering timehas always been a plus for me. Greater versatility as compared with fixed, slower renders on other platforms.
Also-- (we’ll call this a postscript ) frequently mentioned in the other threads by myself and others: the Steinberg plugins included with Cubendo often render radically faster than some third-party plugs (UAD is a good example of that, although the UADx versions have sped things up substantially)
The export is being slowed down…by that I mean it’s using smaller buffers during the export than when you’re doing playback with asio guard. Using smaller buffers obviously slows down the export. If Cubase simply used the same buffer sizes during the export as during playback, renders would be faster (plus the export would be a more faithful rendering of the project). How much faster? It would be as fast as the large buffer example in DanielAyo’s video above, which means there would be no need for the workaround of adjusting the buffer size prior to exporting.
I don’t think there’s any question about that. The buffer sizes are indisputable. As a plugin developer, I’m intimately familiar with this issue, but anyone can watch DanielAyo’s video to see evidence of this.
The only question is: is there a reason for slowing down the export like this? It’s hard to fathom how there could be, especially since other DAWs don’t do this. But it’s possible Steinberg has an explanation.
before Cubase was M1 optimized, it was advised to keep it off because it could even cause crashes. But anyway, I think it is besides the point. The actual culprit is the buffer size, not Asio Guard - two different things.
