ASIO meter question

Cubase
1

Hey guys I can’t believe I never noticed this before after decades of using Cubase, but it’s probably because I never looked. If my ASIO meter is about 90%, and I open task manager (I’m on Windows 11) and check the CPU usage, it’s only at about 13% (I91400k). Why is there such a discrepancy between the ASIO meter and the CPU? I’m assuming that it is bottle necking at the PCI bus speed? The CPU itself could work much quicker and much more efficiently at processing audio if the bus speed where faster?

Am I right on this or wrong? If I’m wrong, which I probably am because I’m just making an intuitive guess, then please explain it to me and how it works because I’m extremely curious. Thank you to everyone that reads this and replies in advance!

2

I think a way to think about it is that if you have a long chain of very heavy processing, where one process has to finish before the next one begins, you may have a long thread of processing that ends up on one core on the CPU. If you max out processing on that CPU core then the other cores are still available.

From the perspective of Cubase it’s a problem if that core can’t keep up with processing. You’ll get drop-outs if that happens. So from that perspective it’s useful for us to have a meter that says we have a problem. From the perspective of the operating system however there are all the other cores that are not maxed out, and therefore the CPU as a whole is not utilized 100%

I think that’s a good approximate way of thinking about why there is a difference.

3

It would be nice if Steinberg let us know why this is happening in their program so we can buy the right components to try try to make the best of it.

4

There is no particular requirement for a process waiting on another process need be restricted to the same CPU core. While that MAY be a factor, I think it is more dependent on the fact that Windows was never designed as a real-time OS and that CPU core and thread scheduling is not a trivial thing. This is compounded by the fact that the details of Windows scheduling is not exactly obvious and that now modern CPUs have a mix of CPU core types with differing capabilities compounding the situation.

A program attempting to run as a real-time environment MUST consider a number of things to manage emulating a real-time application on a general-purpose OS and coexist in an environment where the OS may not behave in a friendly manner.

I don’t have specific insight into how this is done with Cubase and Windows 11, but to be successful the OS must provide mechanisms to give the application substantial control over how a preemptive OS manages memory, CPU cores, and I/O to be successful.

Many third-party applications have appeared to assist in overcoming historical performance issues by side-stepping how the OS uses resources. These solutions generally can help, but can also expose other limitations that are not obvious.

Of course, none of this removes the frustrations of an application demanding of resources and attempting to behave as a real-time application lacking OS support and cooperation, and the assumption that the application developers have an adequate understanding of how the OS is limiting them.

None of this is meant to be an excuse! Moreso, a perspective on the complexity of the task.

In light of all this, it gets incredibly frustrating that there is not specific public guidance on what tasks should be suspended or priority managed, CPU core utilization, hardware interrupts, poorly operating hardware or drivers, etc.

Cooperation between Microsoft and external developers is required to solve some of these issues prior to forcing a move to yet another major OS version before solving these issues. This begs the question whether there is sufficient demand from the categories of applications requiring this attention.

5

I understand that, which is why I used the word “approximate”. It’s simply a way to visualize why there would be a difference between the meters.

The “real-time” audio process within a DAW obviously means that if I have a denoiser before an EQ before a compressor they need to process that in the order they appear, and the OS meter simply doesn’t care about the outcome of that if it fails.

Also, did you use AI to write that response?

6

No, I did not use AI. Not sure where that came from.

Granted, I was a bit loose with the term “process” where, in some cases, task or thread would be more accurate.

7

Could it be easier to manage on a recent Linux ?

8

That’s a really dumb question to ask. It appears that you feel your ego has been damaged by his much better, excellent, and detailed reply, so you’re trying to belittle it (and him) by asking if he wrote it with AI? It’s obvious why you went there and I just explained it. Can we please keep that kind of mindset off the forum, please? If you want to act like that on social media, fine, that’s typical and par for the course on those platforms (unfortunately), but I really don’t want to see that behavior here. That’s the kind of stuff that gives me incentive to just stay away from the forum, unfortunately, because it’s ridiculous and extremely unbecoming.

9

Dude, where in his reply did he even talk about why there is a discrepancy between the Cubendo meter and the Taskmanager one? Basically his entire post is about threading, not about the discrepancy, which is what you were asking about.

And that’s why I asked if it was AI, because it seemed to not actually answer your question and didn’t negate what I said.

I’m sure it’ll be a loss for everyone else if you just leave, so maybe just put me on ignore instead, like I will you.

I tried to give you a good-faith answer to address your actual question because contrary to what you seem to think that’s what a lot of us try to do here.

So you can take your assessment of my personality and store it somewhere presumably warm.

10

This has to do with Cubase’s core handling, which does not make good use of modern multicore cpus. There is a very long and detailed thread on it here:

All the best

Magnus

11

Maybe! Linux is also not a real-time OS, and the difficulty with hardware configurations and drivers, interrupts, etc. remain. Arguably, access to all the related code might lead to more open solutions. However, all your VSTs and supporting software would also need to be implemented.

In my case, this would include Dorico, Wavelab, SpectraLayers, Arturia V Collection, etc. and seems unlikely to happen.

12

Thank you Dave B (Save A :slight_smile: ), great answer to a puzzle that hasn’t held me back, particularly, but I have been curious about for many years.

Please don’t leave.

14

To halioninreverse Just said this to Dave B, probably meant you:

Please don’t leave!

15

Uh huh​:roll_eyes:

16

I bought the i914900k because of its speed and 8 performance cores. If my ASIO meter is 90% while my processor is only 13-14% in use it defeats the entire purpose of having bought that processor, and it was a waste of money. That’s completely absurd if Cubase is handling multiple cores THAT BADLY. It’s absolutely insane, and if Steinberg has not addressed that for this long, then that’s a red flag to me that either they don’t care, or they are unable to fix it. If that’s the case, and they aren’t going to address it or fix it, then after this project/album is finished I’ll move over to Universal Audio’s Luna and give that a shot since it is already installed on my computer with all of my other Universal Audio stuff and DSP cards. I’m just shocked right now that Cubase, after decades of using it, is that inefficient. I love the program because it’s intuitive interface and everything about it, but if it is going to continue to run like crap and so inefficiently I don’t see a logical reason to keep using it. To keep using it would be completely irrational at this point.

17

I feel your pain, and I appreciate your comment on my attempt to elaborate a bit, even if opinions vary on the degree to which I addressed your question.

I’m not intending to make excuses. Moreso, attempting to communicate the challenges. I share your pain, especially in clear instances of what appears to be lack of automated regression testing.

Granted, things have gotten more complicated, but it’s extremely frustrating using a machine orders of magnitude greater than the Atari ST and having the same problems or problems that didn’t exist in earlier versions.

I can only speak for the time I have invested in workarounds and speculate how much time others have invested, while also trying to be fair to the complexity of the problem.

I wish I knew the answer to getting the various vendors to cooperate in identifying performance bottlenecks and coming up with solutions.

However non-trivial or non-intuitive, when you choose to produce a product for profit, it should perform as expected.

I’m not very amenable to trotting out my resume to “prove” I know a bit of what I speak. That said being retired from a 50+ year software development career and 20 or so specifically in an embedded and real-time OS environment, gives me enough background to be annoying! :wink:

18

Yes a product of this price should work as expected when profiting off of it. You nailed it 100%.

I’m glad you are here (especially with your background and experience) to point these failures out because just maybe, Steinberg will actually listen. Putting pressure on them by shining a light on these failures consistently and repeatedly is the only way it will possibly be fixed. In fact everyone should start commenting on this post to keep it at the top so the glaring problem gets fixed. Until it gets fixed I’m going to start using Luna after this project is done which pains me to say it, but given the complete and total lack of failure to address this issue and make a program that runs efficiently, I would be an idiot not to go move on to something else. I’ll also be trying to find out what software actually runs the most efficiently out of everything out there. I’m not giving Steinberg any more of my money until they address this obvious and glaring issue, I would suggest others do the same because the only way to this is going to change is when it effects their pockets, just like every other company out there. That is the ONLY thing that has ever worked through out history. People have more power than they realize.

19

I think it’s because of a bottleneck.
That even though most of the cpu is at rest, there is one thread that has that 90% load on it. The music has to be linear and wait for all things to be calculated before it can continue, so that music making remains real time. So the cpu meter goes by what is the slowest cpu thread. If that gets behind then all other things have to wait for it, regardless of how much cpu threads are still idle.

21

If that’s the case then that still sounds to me like Cubase is STILL completely inefficiently using multi-core CPU’s. That’s pretty much what you have just described.

22

One thing I haven’t noticed in this thread thus far (but maybe I just missed it): Are you actually having real performance problems, with audio cutting out or breaking up, when the ASIO Guard meter is running a high percentage while the average Windows CPU meter is showing a much lower percentage? A few things to mention, depending on the answer:

First, if you’re not actually having problems – i.e. it’s just a meter reading discrepancy – why do you care since your computer is keeping up with what you’re asking to do? I’ve sometimes had very high ASIO meter readings, especially during a mixdown, while my (i9 285K) computer is keeping up just fine. I only worry about the meter readings in the case where there is an actual problem.

Second, even if you are actually having problems, I suggest not looking at the overall reading for Windows. Look at the CPU tab in the Performance tab of Task Manager instead. That will show you how well (or not well) spread out process are against your CPU cores. You may find that the load is spread decently well, but one core is maxing out.

Third, if this is the case (i.e. one core maxing out), while it may seem counterintuitive that it would help, try giving a shot at “the HALion trick”. Specifically, add an instrument track with an instance of HALION Sonic (you don’t need to actually pick a patch within it), and put the focus on that track to put it in record mode (assuming your preferences do this automatically – if not, you may need to manually put it in record mode). What this does is force Cubase to create a real-time thread, and, in many cases where your system isn’t really overloaded, but things are bottlenecking on one core, and adding the real-time thread somehow gets Windows (and/or Cubase) to readjust the process allocation, which “magically” (i.e. in terms of my having no clue why this actually works) resolves the audio breakup/dropout issue. I had to do that quite a lot on my old Windows 10 system (i7 5820K), not so much on my current Windows 11 system, though occasionally I still do when working on mixing with a lot of heavy-duty plugins and complex bus structure.

This is not to excuse any inefficiency in Cubase’s or Windows’ thread allocation that may (or may not) show up in other DAWs running on the same version of Windows with the exact same drivers and all the rest of the “unruly” mix of things that has to go on in a Windows system as part of Cubase and/or Windows. Hopefully things will improve in the future, but there are some general limitations in terms of what can and cannot be effectively parallelized in any given audio processing chain. ASIO guard just helps (at least potentially) take parts that don’t have to happen exactly in real time and avoid encumbering the real-time audio processing thread that does need to respond in real-time (e.g. for monitoring a virtual instrument while playing it). Ultimately, though fully-calculated samples do have to be fed to the ASIO audio drivers fast enough to not drop samples on playback, even if some less critical parts are calculated and “buffered” (whether literally or just conceptually) ahead of time.