Exactly, and I think this is what we are all saying in a variety of ways to visualize and express it.
I tend to use the term real-time more literally, but it is not really that a real-time OS is required. However, as you stated, the CPU, I/O buffers, caches, etc. do have to complete all the work required for all the channels within the time between audio samples such that buffer underrun never occurs.
To complicate things a bit further, the audio interface hardware, drivers, and any and all VSTs within the project must also complete their processing within the sample period. While Cubase cannot control these aspects, it can, with proper test code, detect misbehaving code by monitoring how much of that interval is being used, and I think it would be somewhat accurate to say that this is what ASIO metering is trying to show.
At the risk of telling you what you already know, some aspects of this are not directly related to OS/CPU resources. However, the OS/application together should be able to monitor and identify problem resources. Judicious use of hardware timers can assist in identifying external interrupts that take too much time for example. Scheduling of OS cores for external non-audio hardware should be able to mitigate the effects to audio flows.
Per your suggestions about forcing the software to change how it schedules things, this really goes to the point I think most of us are trying to make. End users are too often discussing, “try this”, “try that”. To the extent that the OS and application do not cooperate adequately and do not offer clues as to external causes, this seems to be an area ripe for improvement.
I worked on many projects where it was disheartening to correct corner cases and the associated complaints from customers. Luckily, in the end, I had partners in system and regression testing and together we understood that the customer experience is paramount. To top that, all the equipment at my final job before retirement was used in live entertainment and broadcasting where dropouts were unacceptable. Failure literally meant losing business to other providers.
To add to the previous, that’s the rub with some of the audio “glitches” sometimes they were totally unrelated to ASIO performance. Rather they appeared to be external interrupts introducing latency or higher priority services/tasks taking control (such as the reliable 15-minute glitch documented a couple years ago).
I don’t recall the exact task that was identified, but if memory serves me correctly, it was related to a periodic hardware diagnostic service introducing DPC latency.
Whether or not audio is dropping out (sometimes it does) is irrelevant. It is an expensive product and shouldn’t be hanging up on one core when I have 8 available. That is the most inefficient thing I have ever heard of, it defeats the entire purpose of having 8 cores. It’s the principle. If I have larger projects come along, I’m screwed even though I have 8 cores, and 7 of them are doing nothing because it seems Cubase isn’t even addressing them at all. It defeats the entire purpose of spending the money I spent on that CPU. That should not be at all, and this should piss off everyone that’s paid for it, you have paid for a faulty product that is completely failing to work at its full potential (1/8 of it to be precise), and the fault it seems, isn’t being addressed at all from version to version. How can they in good conscience, release a Cubase 16 (which they inevitably will) and not fix this problem yet? That is unbelievable to me. Keep in mind I’m using an RME MADI PCIe card with the buffer maxed out 4086, and they make the best drivers out there. So if you’re using a card or interface that’s not quite as good as an RME the problem will probably be even worse.
While this is NOT a Luna forum, if you do decide to move to Luna, I would appreciate if you PM me at some point to discuss your experience.
I’m also using several UA plugins with a Quad card.
To perhaps my fault, I’ve been stubbornly loyal to Cubase in spite of the difficulties since the Atari ST days because I like their approach and am familiar with it and because I also use other of Steinberg’s products.
I would MUCH prefer these issues get resolved, even if the next major release is nothing but solving these issues.
Luna is seriously underdeveloped compared to Cubase, especially with automation, MIDI, lots of editing, etc…
But I indeed agree with encouraging Steinberg to boost efforts towards efficiency and stability. I’ve had a lot of crashes, dropouts, etc.. And have tried dozens of tweaks on Windows 11. I cannot say I fixed it or not, issues seem to randomly come and go at times.
But I still love Cubase it is just the best UI I’ve used in two decades of trying music software. If they can improve the core handling and clean up the UX it’ll be a blast !
Pretty much in line with my experience and continuous threads for years. I WANT to stick with Cubase and used it multiple years with success on lesser machines by extensive use of freeze, bounce, etc.
While the capacity and features have grown considerably, the changes in resources of more modern hardware, available memory, etc. are MASSIVE.
The amount of time “wasted” on web searches, experiments with Process Lasso, Park Control, DPC analysis, etc. is massive. In many cases, these solutions solve some problems but include uncertainty about what problems they introduce.
One discovery that has been mentioned is getting much of Cubase off of CPU core 0. This begs the question, why is this relegated to the end user?
While CPUs are massively more complicated that say the 68000 or 68020, pretty much every aspect of modern CPUs, from multi core, massive amount of fast memory, multiple layers of caching, faster base clock rates, solid state drives, etc. should lead to better outcomes.
This is an absolutely absurd response. They won’t code their software to use multiple cores when multiple cores are available and have been available for over 12 years or more now? That’s exactly what is happening, Cubase is only using one single core. That NEEDS to be fixed ASAP, and if they refuse to fix it then I’m moving on which is heart breaking since I’ve been using this since I was a teenager (I’m now 50). So screw them I’ll move over to Reaper or Luna then. This is absolutely absurd.
It was just the style of writing, which looked more organized and “well” put together than what most people manage. I’m just trying to get a feel for when people use AI so I can tell moving forward. Some aren’t forthright with it.
I see. I think we were just talking about slightly different things.
I don’t think people disbelieve you.
Exactly.
And for the record, the point is that all it takes is one thread to max out one core for there to be a potential problem, and not that Cubase only uses one core.
He also wrote (in the same thread):
“we’re not planning any major changes in this area within the Cubase 15 development cycle. Because of the high complexity and interdependencies involved, these efforts need more time if we want to get it right.”
My guess is that it’s unlikely that there’s going to be major improvements before v17.
That’s fair, I suppose, and a bit more palatable than, “You didn’t even address his question!” I appreciate the clarification.
Regarding the omitted portion of the post. I wasn’t expecting miracles in the Cubase 15 release. Your guess of v17 may be right on, but I find that a bit disappointing. While changes in Windows 11 may be beyond the scope, some of these resource issues have spanned multiple releases and are not unique to Cubase 15 nor Windows 11. THAT, I think is where the patience wears thin!
When I read this trick of the Halion selected track just to create a ‘real time’ thread just to force w11/cubase to reorg their priorities, a question raises : why Cubase do not do this kind of trick by itself with a lot of economy in resources and project ‘bizarre tracks’ ??
Agreed. There was a long thread on this back at Cubase 14.0.20. I did some specific tests on the old Windows 10 system I was using at the time, including taking some screenshots of the Windows-level CPU performance meters with and without the “HALion trick” (BTW, it doesn’t necessarily need to be HALion – most any VST3 instrument in record mode could do the same thing – perhaps an audio track with monitoring on could as well):
There are some very interesting follow-up posts by a few different people below that part of the discussion (which itself is about halfway through the thread), including one late in the thread that also shows a big change in the ASIO Guard meter after having found this “trick”.
One of my thoughts (later in the thread) was:
Even that could be a workaround (since the ultimate need is for Steinberg to overhaul the audio engine, but, as discussed in many forum threads, that is a huge job, with lots of risks, so not any quick fix), but within Cubase itself, instead of something for users to have to do (and maybe having to stumble upon if they weren’t already aware of it – I think the first time this workaround surfaced was in Cubase 14).
Yes. I remember at one point (probably on my old Windows 10 system) noticing that there was a specific time in the afternoon on weekdays where there was an increased chance of issues. I don’t recall at the moment if I ever nailed down exactly what it was (I do know I would have looked through scheduled tasks, but I probably didn’t go into all the depths of what Windows does on that front), though I do think I found one common contributing factor was Edge browser updates, and it may have been that Patch Tuesday downloads were also coming into play. (I have not seen any similar issues on my current Windows 11 system, but that system is more powerful on pretty much every level.)
I think we’ll have to agree to disagree on this point. For me, whether audio is dropping out or not on my (sometimes simple, sometimes complex and heavily demanding) projects is the point for me. I need to be able to hear playback at all stages from tracking to editing to mixing and mastering in order to do my work and make informed decisions. I don’t really care what any meter reads – it is just an analytical device that might help me localize where a problem may lie in the event a problem does develop.
I would rephrase this to say it should use whatever it needs to do the best job it can, whether that is doing everything on one core (unlikely, and not “real life” in terms of the way Cubase actually behaves), using every core available to it, or doing something in between. But there are also some inherent limitations in what can be parallelized.
That said, you mentioned having an i9 14900k CPU. You might want to check out this thread in the forums:
Beyond a link to another thread that discusses those problems, there is also a link to an Ars Technica post regarding microcode updates that could potentially be applicable if your system does not already have the updates.
Well, it’s not on my system. But CPU usage at the general task manager level is just an average across all cores. What you are calling the ASIO meter is actually the ASIO Guard meter and measures only what the audio that is able to be pre-processed, using a larger buffer size than what is set on your audio interface, trying to offload the parts that don’t need to be happening in real-time instead of having to process all audio in real time.
There’s a good explanation of this at:
I honestly have no clue what the ASIO Guard meter’s percentage measure relates to, but one thing I have seen is that it doesn’t seem to scale linearly. That is, it may go up to some level, but then I add more that would go on that thread and it still doesn’t go up, and it I keep on adding, and things are still okay, at least to a point. (Of course, every system can be overwhelmed at some point, especially with some intense modern plugins.) This is partly why I asked if dropouts are actually being experienced.
Well, I’m using a MOTU 828x that I got back in 2014, and I’m not seeing this issue (on my i9 285K Windows 11 system). I run at 96 kHz, so the maximum sample buffer size with that interface is 2096 samples, but I only use that when mixing. I mostly run at 256 or 192 sample buffers, and those get me all the way through the arranging and tracking stages of my projects. (Sometimes I forget to raise the buffer size for mixing, but, most times, some heavyweight plugin’s addition will end up reminding me.)
FWIW, I have done absolutely nothing in the tuning areas you are suggesting with my i9 285K system, nor have I done any BIOS performance tweaks (on my ASUS UF GAMING Z890-PLUS WIFI motherboard). I have, of course, turned various WIndows 11 bloatware-style annoyances off, but I also use my system for all kinds of things other that Cubase (e.g. Photoshop, Lightroom, various MS Office products including Outlook and Access, DaVinci Resolve, etc.). It is rare for me to run into audio streaming issues in Cubase 15, and the few times I have either “the HALion trick” provides a workaround or, if that also doesn’t do it, then I may need to close down Cubase and start it again (I do have a sense that a very long Cubase sessions, especially making lots of mixing-level tweaks that end up with a very long MixConsole history, start to weigh it down, so maybe clearing that does something?).
I have had the processor replaced under warranty with a new one. I’m aware of the issues, and that isn’t the issue here
That’s kind of the point. If Cubase was using all of the performance cores properly you wouldn’t be having drop outs at all. They wouldn’t happen at all for anyone. Since that is the most important thing for you, you should want exactly the same thing that I want, a properly working product. When someone hands you a gigantic project you’ll start experiencing dropouts, especially at 96k (that’s what I work in). What then? Will you still “agree to disagree”? I hate that term by the way, I see it as intellectual cowardice. Will it still be ok then? You just haven’t experienced dropouts YET. You get my point now? Regardless, the product we ALL paid for should still work correctly, and we should not even need to be having this conversation 2 decades into multi core processors being around.
That may be so. I have not taken the time to stress the Cubase 15 system with Windows 11 yet but spent significant time in a variety of tests and solutions between Cubase 11 and 14. Many of my results were confirmed by others working the same issue.
I had some early issues in both 14 and 15 that were mostly resolved in later point releases. A few of us did a pretty deep dive with both Windows 10 and 11 on multiple machines with differing processors and confirmed that excessive reliance on CPU core 0 was a key factor.
Multiple people confirmed the 15-minute DPC issue, and depending on your use case, you may or not experience it. This one I can’t specifically “blame” on Cubase, thus my mention of cooperation with Microsoft to determine what this 15-minute interval was doing that caused delays in processing in Cubase.
The obvious symptom (regardless who is at “fault”) was this concentration of execution on core 0 and that moving some of the processing to other cores appeared to solve the issue.
At some point I will probably load up Dom’s Cubase stress test 15 and see what happens. The entire point is that end users should not be concerned with whose “fault” the problem is, along with the classic multi-vendor scenario of pointing elsewhere.