Cubase should spread loads more evenly across all cores
I can’t believe that this did not get addressed
If you use more than 8 cores, stability at very low latencies is kind of lacking. I’ve had to disable hyper-threading for this very reason.
Jorge, may I ask how low of latency you can get? I have a similar system and wondering if I should turn HT off. I currently run massive sessions at 2048 buffer with HT on.
For example, when loading a project in Logic Pro X, you see Kontakts load in parallel - at the same time. In Cubase, they load one at a time. This is tremendously inefficient.
6800k on X99, NVIDIA GTX 1060 6GB
128k buffers in Cubase, no problem with HT ON
Even can run Elektron Overbridge via Overhub at these buffers.
Sure. I find the peaking really severe at 64 samples, even playing a single (and monophonic!) VSTi in an empty project, or simply opening editor windows, I experience the audio stuttering very often. When this happens, sound completely interrupts, which is really annoying. In this same scenario but with hyper-threading off, I still see the Cubase real-time meter go to red from time to time, BUT it has absolutely no effect over the audio flow, I mean, no interruptions or cuts.
As this seems to be originated by some kind of synchronization troubles between multiple cores at very low latencies, my guess is that aptmusic9 won’t see a big improvement in stability switching hyper-threading off, because he already runs his projects at high latencies (2048 samples). Also, letting hyper-threading on, he will get better plugin counts.
I was really hoping they would address this issue! It’s starting to become a real problem for me now that my template has grown exponentially.
Wouldn’t change my DAW but please come on Steinberg!
The problems you expose here look related to HT, rather than multi-core.
As you probably know, ASIO Guard was introduced to take advantage of hyper-threading - still, virtual cores cannot be used as efficiently as physical cores for real-time processing.
The CPU cost at low latencies is much higher and handling real-time is more difficult.
Also, differently set up projects will behave differently, for example, if you load 32 instances of the same VSTi, these are spread evenly on different cores - if you load two instances with 16 patches each on two channels instead, these will be assigned to two threads (which cannot be spread over, say, 8 cores).
Of course one should not have issues running one single VSTi - if you think you have this kind of performance issues, please get in contact with Support to have a deeper look (with computer specs, amount and type of plug-ins used, audio / MIDI devices connected, driver revisions, buffer size used and anything you think is fitting).
So, Fabio, generally speaking people with 6 cores (12 virtual) show disable hyperthreading, and work with the first 6?
That would give more asio and asio guard stability?
well, not really. Modern CPUs in combination with HT should work - one should just not expect twice the performance when activating HT. The actual performance benefit and the overall stability is very much system dependent.
Now, stuff like this would need large-scale testing to make any final, reliable statement, but we noticed various things in common on computers that have bad performance. It is usually a combination of factors. You might have seen this post: https://www.steinberg.net/forums/viewtopic.php?f=198&t=96655&start=25#p536524
Additionally to that, PC configurations with mismatching CPU / RAM timings (especially on certain chipsets) usually have more severe performance issues. Real-world example: a CPU supports 1333/1600 RAM modules, but the system is built using 2400 modules clocked to 1600 (which is what I’d expect to see by default).
Again about that post, I have to correct the ‘OpenGL issue’ on the Mac. That was my impression back then, due to the many crashes / hangs on graphic OpenGL related tasks, but it was actually triggered by the Objective C problem discussed elsewhere.
Hi Fabio, thanks for the response (this is what we mean when we talk about Steinberg folks interacting here!)
I wanted to ask you about that sentence because I think I have a very similar situation in my rig.
Do you mean that a 2400 memory underclocked could be bad for performance?
After reading these posts, I quickly activated HT in BIOS and activated ASIO guard, and the VST performance meter is showing lower readings now. I always had problems with ASIO guard before, but now I understand why. So it’s a nice Christmas gift for me.
Yep, never trust old hearsay internet wishdom from a couple of years ago. Times have changed, systems evolved.
very complex topic, I’m afraid. This boils down to the PC configuration and components used.
Different RAM modules could behave differently, the chipset used also make a difference and the same chipset from different MoBo manufacturers could behave differently, the CPU model also plays a role, of course. I recently had a very lengthy (and useful) discussion with a DAW builder on related topics…and… just, wow
I’m no specialist here, a system builder with experience with many different components or a tech with experience with overclocking and real-time applications could help better.
Frankly speaking, I always buy components which match perfectly, all up to the maximum supported stock speed just to avoid messing with this stuff.
The problem is the internal multiplier, which can do odd things, another example: I have a PC (not a DAW) with a CPU supporting max 1600, with native 1600 modules. For some strange reason, the BIOS clocked the RAM to 1333. I experienced odd crashes and started trouble-shooting the installation, to no avail. Until I found the mismatch in the BIOS, set the memory to it’s 1600 native speed - never had a single crash or instability since then (6-8 months ago?)
I mention this because if you have a CPU / RAM mismatch, it might be possible to find a ‘sweet spot’ that makes all work fine - the RAM speed is determined this way: RAM Speed = Base Clock Rate (BCLK) * Memory Multiplier, so playing around with those values could help. People useually buy faster RAM when wanting to OC.
But let me add, boldly that this should be done by people with experience in this field - I would not do that myself.
This is not “old hearsay internet wisdom” by any means. This is what some of us are experiencing with our specific systems. Regarding Cubase, multicore support and low latencies, Fabio Bartolini himself explained the actual state of things on this really informative thread from just one week ago:
I’m talking about advised tweaks, my system runs better with HT ON, Turbo ON (6800K on X99)
I’m on Win10
The reason that I deactivated HT in BIOS in the first place, was because it says so on Steinbergs Website in this article on how to optimize DAWs in windows.
- Disable Hyper-Threading if your CPU supports it (e.g. Intel i7) and you use older sequencer versions than Cubase 7 and Nuendo 6
So I did and ever since my VST performance meter peaked, when ASIO guard was enabled. So I was a bit surprised to read in the post from Fabio, that activating HT is preferable. So I tried activating HT and Asio Guard, and VST performance meter shows no trouble. So maybe Steinberg should change the guide info. Or maybe I am misreading the text, so I says only deactivate HT, if you are running older versions of Cubase? Maybe they should change the text to ONLY disable HT if you run older versions of Cubase.
did I really say “preferable”?
Yes, the part you’re quoting means it should be disabled with versions older than C7 and N6.
Should be OK with later versions, due to ASIO Guard, but then again, the outcome is really specific. We’ve seen a few fairly recent configurations which improved the overall performance with HT turned off and we still recommend to at least test with and without when problems occur.
We revised the article pretty recently, but if the wording is confusing, then it’s worth having a look at it again.
just info, I had to disable HT again and stop using Asio guard, it crashed cubase,