best duel xeon configuration for cubase 7.5

WaveLab
1

Assuming one is going to purchase a duel xeon daw workstation, which of the cpu’s below would be the best performing and why?

Xeon E5-2650 v2 8 2.6 GHz 20 MB 95 Watt $1335.85
Xeon E5-2650L v2 10 1.7 GHz 25 MB 70 Watt $1395.91
Xeon E5-2660 v2 10 2.2 GHz 25 MB 95 Watt $1590.78
Xeon E5-2667 v2 8 3.3 GHz 25 MB 130 Watt $2320.64
Xeon E5-2670 v2 10 2.5 GHz 25 MB 115 Watt
Xeon E5-2680 v2 10 2.8 GHz 25 MB 115 Watt $1943.93
Xeon E5-2687W v2 8 3.4 GHz 20 MB 150 Watt $2414.35
Xeon E5-2690 v2 10 3 GHz 25 MB 130 Watt $2355.52
Xeon E5-2695 v2 12 2.4 GHz 30 MB 115 Watt $2675.39
Xeon E5-2697 v2 12 2.7 GHz 30 MB 130 Watt $2949.69

How many cores/threads can cubase 7.5 actually handle?

2

i read a post on “toms hardware”

the responder is saying that Cubase is…

“one of the few applications outside the world of rendering that can use all the CPU cores available.”

im not sure if this was meant as a literal statement. Can Cubase really use up all the cores you have no matter how many?

then goes on to say that it “doesn’t recognise hypo threading”

not sure how to read this…the cubase documentation says that the new drivers now enable the exploitation hyperthreading without causing critical spikes on cores preventing low latency processes from be able to be executed in a timely fashion.

hoping someone can chime in and confirm what Cibase 7.5 supports and what the ideal xeon CPU would be to select.

3

Yes, Cubase will use all cores, no matter how many.

Cubase 7+ with ASIO Guard and hyper-threading on, is the best combo for most use-cases; in theory and what I have found, but other users have reported turning off ASIO Guard helps them.

If you, for whatever reason, do not use ASIO Guard, then disabling hyper-threading in the BIOS may be helpful. Audio likes real cores and that are not being pestered by hyper-threading.

4

:wink: Might get better performance if the Xeons are not battling each other :wink: DuAl, not duEl :frowning:
Sorry, couldn’t help myself, but then it just turned 2014 here!

Anyway, I have a quad core, and the CPU meter I have still shows C 7.5 is favouring one CPU core, and the peak Performance Meter seems to track its use, with noises when use for that core hits 100%.

I was considering going for 12-core Xeon E5-2697 v2 (even singly), but given that CPU core bias, it may still be better to get a very fast consumer CPU with less cores, and overclock it.

Unfortunately, the RME Firefaces only go to 2048 sample buffers at 192k, so it looks like I can only up the clock speed to get better performance. I cannot use REVerence in four channel mode at all, and even two channel sometimes peaks out. Fortunately, I have a UAD2-Quad, and it seems to have plenty of capacity to spare for the few FX we use.

At least when tracking, where we use no FX, I can run at 256 sample buffers, getting ~1.4ms record and ~2.8ms playback latency, despite having a constant system DPC latency of ~1ms.

I have tried to determine why the system latency is so large, but since it was around 300us when I had NVidia video cards, I suspect it may be due to the ATI2460 quads’ driver.

5

Under 7.0.6, I seemed to get more stable performance with ASIO Guard off, but with 7.5, it is better with it on.

6

That guy also says that

Cubase does not recognize hyperthreading.

That true?

7

Not really, it’s poorly worded. Before version 7 it was more, not benefit (and often hurt), than not recognize.

Version 7’s “ASIO Guard” does now benefit from Hyper-threading.

Cubase, or any app, has no way of not “recognizing” Hyper-threading. The OS is presenting two virtual cores for every real physical core. It’s doing that at a very low level that software applications don’t have to (and can’t) know the inner-workings of. That’s the whole point and benefit of it; “it just works” with existing software. It just didn’t work very well for audio applications that were designed primarily for live monitoring at low latencies, like Pre-7 Cubase was.

8

Btw, this might be the best demonstration of the whole VST Real-time CPU Meter spiking issue, without ASIO Guard, I’ve seen:

It’s a long 14 minute video, much of which is spent watching repetitive cut-copy-paste operations.

But if you follow it closely and watch (and understand) what’s going on, you’ll see the following…

Cubase 7.x (with ASIO Guard OFF) with Vienna Ensemble Pro 5 running on the same PC, at the same time.

Cubase struggles to run even a few instances of Aether reverb.

The user then moves the reverbs to VEP 5 where it’s able to run tons of them using much more of the available CPU.

Cubase is also set to have multi-core turned off so that it can hog one, unfettered core.

Everything plays very well at this point.

As soon as the user turns on multi-core in Cubase, that’s being used up by VEP 5, you can see Cubase immediately spike. This is similar to a hyper-threading situation.

Unfortunately, the user never demonstrates how this configuration would have worked with ASIO Guard turned on, but my guess is that it would not have helped in this situation, as VEP probably appears to Cubase as a “live input monitoring” use-case (not sure, and would love confirmation on this). But for “normal” plugins, it would have helped. Would it have helped as much as running VEP on all but one of the cores and letting its engine do its thing? Ahhh, my guess is probably not. I don’t think ASIO Guard is that good yet. But again, it’s version 1.0, surely it will get better.

In the meantime, if you really want to use Cubase and really want to squeeze every last bit out of your computer (or multiple computers) VEP 5 may be a viable option.

In the video, Cubase is restricted to only one core which may not be practical depending on what you’re doing. You’d have to use VEP for just about everything.

But, you could get around this by using Windows “Affinity” to limit Cubase in multi-core mode to say, 2 cores and then let VEP have the rest.

9

@Jalcide
It sounds like it would be better to be able to limit VEP’s core use, if that’s possible. Otherwise, it’s the tail wagging the dog!

10

Ha! Great use of that idiom. Yeah, the Windows Affinity could be set, either way.

But my guess is that VEP will make much better use of those cores.

Here’s another video demonstrating that.

It shows VEP getting half the CPU utilization, or twice the number of plugins (same machine).

I think Cubase is still being somewhat artificially held back with its ASIO low-latency heritage. VEP gets to enjoy mostly not caring about that. And it has extra large buffer multiples to play inside, that Cubase doesn’t. It’s unclear in the video just what those buffer sizes were.

If the tester kept it at “1x” (one times, or no change in buffer size) the buffer Cubase was stuck with, then it’s really doing a great job. But it may be enjoying a 2x or even 4x buffer size in which case the test is “unfair.” Unfair in quotes because as far as I care, when I’m mixing, it could be 4x (high latency) and I’d be fine with that.

But, I’m pretty much sold on the VEP + Cubase approach. I’ll be running it on a dedicated slave, rackmounted PC.

I’m tired of f’ing around with performance issues. My new year’s resolution. :mrgreen:

Once I get it all setup, I’ll share the results.

11

When it comes to pro audio, IMHO clock is king. Which means the Xeon E5-2687W v2 8 3.4 GHz will probably get the best Cubase performance.

12

I’d suggest the VEP approach as well, if you’re dealing with huge templates… and set up as many slaves as you need. With good budgeting, for the money of a massive dual socket xeon workstation, you could then get yourself a high-end, quality single CPU machine as the master, and build a couple of VEP slaves with nice, but very simple i7-4770k configs, for example. That would give you incredible flexibility and power.

If you need the absolutely best low-latency performance in one machine, according to DAWBench (search for TAFKAT and trust his numbers), you’ll do best with a higher-clocked CPU in general. And frankly in that case, the choice of audio hardware is also crucial. RME, for example, will give superb low-latency performance. I can also vouch for Lynx. RME also works great on Macs if you choose that direction.

Good luck!

13

Did anyone ever establish how many virtual cores Cubase can actually use? I’m finding it hard to get clarity on this issue - various sources have told me 32 and 40 cores max, whereas this thread suggests no limit.

I’m spec’ing a new dual CPU system for Nuendo/Cubase use, and would be hugely grateful if anybody actually knows what the score is.

Cheers

Jules

14

No matter what that limit is (and sorry, I don’t have that information), you can of course run VEPro on the same machine as Cubase (not just on satellite computers), which would theoretically allow you to scale beyond whatever Cubase’s inherent limit may (or may not) be. So if your strategy is to build the largest, most powerful workstation possible, there are ways to get around such core limits, if they exist. Good luck!

15

FWIW Steinberg inform me that there is no limit to the number of cores Cubase can use. In theory if you build a dual-12 core system, Cubase will see all 24 cores (48 cores with hyperthreading) and use all of them. Whether that will deliver the best performance is perhaps debatable, but word from the horses mouth is there are no limits, and apparently this has been the case since around Cubase 5.

16

I just read on the DPC Latency Checker website that the utility does not read accurately under Win 8.x because MS has changed the way Windows handles DPC/ISR things. Under 8.1, the checker can just show a lot of 1ms peaks if even a moderate amount of activity is going on. The reality is that the peaks are not all 1ms. They say they are intending to update the utility for 8.x. Generally, I am getting of the order of a few us, but like with all things DAW, it’s the peaks that kill us!

A method of really finding out what is going on with DPCs is outlined at http://www.sysnative.com/forums/windows-7-|-windows-vista-tutorials/5721-how-to-diagnose-and-fix-high-dpc-latency-issues-with-wpa-windows-windows-vista-7-8-a.html, where it also covers using the DPC Latency Checker, but also the Win 8.x options. The MS ADK provides a way of really drilling down to particular excessive DPC instances.

17

Cubase is indeed one of the best real time audio applications for load balancing, Reaper also does very well in this department, however it’s still good to understand how this works in practice.

Cubase can make use of Multiple cores/threads generally when they’re spread over lots of tracks, so for example if you have a projects with 50 tracks( including groups, FX busses etc) which would be pretty normal project these days, then if you have lots of insert FX spread over these channels Cubase will balance them fairly well.

Now say you have a the same project but you have say one virtual instrument channel with a synth like DIVA on it and you’ve also added a heavy CPU reverb as an insert (yes some people still put reverb as inserts! ) and a linear phase EQ then you’ll probably find you’ll have drop outs as you’ll have over loaded that channel which will run on a single core.

In that scenario CPU speed would be of greater use than many threads.

The meter in Cubase isn’t, or has never been a CPU meter in the same way as the windows CPU meter, its an ASIO meter and therefore will show high if only one core is loaded as you only need to overload one core and you’ll get drop outs.

DPC latency is irrelevant unless you’re getting audio dropouts caused by the usual suspects such as WIFI, lan and generally on laptops. People get confused when they see the word latency and think it’s got something to do with Audio latency but it’s not. A DAW will perform exactly the same with a DPC latency of 1 or 500 . As long as it doesn’t cause an audio drop out it’s irrelevant to your DAW performance what it’s running at, and has been pointed out its has never worked with windows 8.


So to sum up: many cores/threads are put to use when you’ve large projects and your plugins etc are spread over the project. High CPU speed is more useful to virtual instruments/plugins on single channels.

Obviously high CPU speed and multi cores in the best option but if you’ve got to choose between a quad at high CPU or a 12-8 core at lower speed then your working methods/type of music/projects will influence this decision.

Hope that’s cleared some things up


MC