The only type of thread I’ve referred to are process threads. That is the relevant meaning of thread for this particular discussion in the context of the OP’s experience on MacOS. If there was mention of any other kind of thread, it was not by me.
But a CPU thread can’t “move across cores”.
Right, but I’m talking about process threads, which can, and do, which would explain what the OP observed.
Ok. So by “process thread” you’re referring to a software thread created by an application.
Then this part does not make any sense.
An application thread simply can’t get “maxed out”.
1 Like
Yes it can, if it fails to complete its task in the allotted time slice. That would cause an audio drop out.
I’m not sure if sticking to “threads” makes this discussion easier. From my standpoint it’s all about resources available vs resources used. My typical project works quite OK until I start monitoring to record guitar or vocals. After that I’m getting drop outs. ASIO guard runs ~25% and CPU usage ~10%. I wish that I could use 50% or more of my setup resources and avoid some drop outs.
1 Like
So do we all 
. But, alas, here in the real world of constraints on latency and opportunities for parallelism, there are limits on what can be achieved.
1 Like
Of course there are limits. But the issue as discussed in this topic (or thread if you will 
) is that ASIO Guard prematurely gets clogged even though there are system resources still available. This can’t be attributed to OS thread handling or core affinity since running the exact same project setup in a different DAW (read Reaper) paints a much different picture.
3 Likes
There will always be unused cpu resources at the point where the DAW starts having dropouts.
CPU power is not an amorphous pool of resource the DAW can freely dip into in order to perform tasks. There are many constraints that limit how much of it can be used.
1 Like
I understand and agree with what you’re saying. But none of your points excuse ASIO Guard’s poor performance.
3 Likes
One minor point worth noting. Except for the unfortunate choice of a label on the performance meter, none of this has anything to do with asio guard
Also, I’m not excusing anything. I’m just offering an explanation for what is happening.
I think that should be (hopefully)clear to everyone :).
The issue at hand is that there seem to be certain scenarios where Cubases ASIO guard meter (whatever that measuresj is maxed out and dropouts occur, even though there doesn’t seem to be any obvious CPU contention or maxed out cores.
At least that is the claim. The problem is that we here have not enough information about the problematic project, how it is set up, the routing, the plugins etc. Seemingly Norbury Brook and/or Tafkat have tested a lot in the past, but unless they share the project file so that we can have a look ourselves, it is all just speculation. The screenshot posted here is simply not enough (as you already mentioned).
1 Like
It does. You can check this by record enable a track to have it moved from the buffered ASIO Guard path to the real time path.
Right, but I’m saying that’s not relevant to the issue being discussed here. You can turn asio guard off and see the same behavior.
@GlennO I’m confused by your responses here reading all this this morning. My impression is that you’re basically saying there isn’t an issue and that the fact thast ASIO guard is overloading to the point of failure with only 20% system, resources is OK…..
If all DAW’s exhibited the same ‘behaviour’ then I’d take that as : ‘it’s how it works’ and leave it at that. The fact that i set up the same project with the same routings/grouping/bussing/plugins etc in Reaper and it DOES NOT exhibit this behaviour should be evidence enought something isn’t working as well as it could.
TBH I”m tired of banging my head agains’t a wall with this. I’ve spent 18 months working with Vin on various projects to show the issue and anytime I make a post , and I only make these posts to try and help get to the bottom of things, people seem to jump on board and say there’s no problem. I’ve just spent the price of a good second hand car to show it’s not a Windows issue like we all thought a year ago and is actually across the board.
I’m going to bow out of this now. I’ve done all I’ll can over the last 18 months so I’ll leave it in the hands of those who can find a solution.
I leave by saying I love Cubase, I’ve been using it since the 80’s on an Atari ST. My posting has genuinely been to try and help find a solution, it’s not been random criticism it’s been well thought out and tested. I want Cubase to be the best it can be in 2025 and continue to evolve and make the most of the wonderful CPU’s we have on both Intel/AMd and Apple silicone available today.
M
7 Likes
@Norbury_Brook OK, but honestly, what do you expect when you post here with a blurry screenshot referencing a Cubase project that no one of us has access to (I checked the dawbench site, to no result)? We simply don’t have the same baseline here, is there a wonder that speculations and miscommunications happen? Maybe you did that in another thread here, I don’t know, but then maybe please reference that? I see several people here trying to understand and learn, but imho you are not making it exactly easy. Not everyone has the same experiences here that you have.
What is the problem? I see no dropouts.
Who is we ?
There is plenty of information for anyone interested, even on other threads on this forum.
I already noted I have opened the session to Public BETA, but unless you have a higher core Mac Ultra, what exactly can you offer me, and/or this discussion ?
We ( as in those of us who have actually given time and energy to test this ) already have enough resources where the session has been tested across a range of M series Macs, as well as across AMD/Intel CPU’s upto 32/64 core systems, so we know exactly how it behaves across a wide variety of systems.
Steinberg were also given the session 18 months ago, and I have written volumes of reports that are all available for those interested enough to look.
For those that actually want to step up and have the facility to test on an Ultra 28 or 32 core, send me a PM, for those that want to continue cyclic debates , peace and out !
@ Marcus,
We were typing at the same time, 100% agree, its time to hand this back to the gallery and let them chat amongst themselves.
3 Likes
I can only repeat that I have merely provided a possible explanation for the seemingly incongruous observation of a Cubase performance meter reading 100% while no core in the activity monitor is reading above 30%.
The existence of such a possible explanation in no way means there isn’t room for improvement in Cubase performance. In fact, I would hope Steinberg is actively looking into issues like this.
1 Like
Could be. But I try not to guess at what the implementation is; it wouldn’t be helpful.
Pete
Microsoft