DAW Stress Test: Logic/ProTools/StudioOne/Cubase

[machinesworking]

this test is crap. cpu usage does nothing to DAW performance. Make this test instead - insert Roland system-8 vsti with default patch and play two notes sequence. On my 4-core cpu Logic Pro can handle only one track, studio one - 3 tracks, Cubase - 4 !!! (MBP late 2016- 2,6 Ghz)
I also made test on the same system with waves CLA Effects - Logic - 480 instances, Cubase - 562. Reaper sucks too comparing to Cubase on Mac. So I don't know how you tested, but your test isn't showing the reality

For the tests to be the same we have to have the same settings. Most of my Reaper settings are default, I let Reaper choose the amount of cores, since that seems to work better than stating the amount of cores your system has, and Anticipative FX processing is turned on, default settings. The latest versions of Reaper have the same thing for buffer size, Reaper adjusts the unarmed for recording tracks to it's own preferences. Since it was showing a latency of 256 for the tracks in the tests I ran I set Logic and DP to 256.

I have heard reports that Cubase is doing much much better on macs after they fixed their low buffer issues, but I would doubt that it would beat Reaper. Again I like Reaper, but it's too much work in general to set up for a fast workflow for me to say it's my favorite. I can't deny the numbers though, in every test I've ever done, it does better than the others. Usually not by so much of a margin that I feel compelled to use though.

What is obvious though is using a DAW like Bitwig or Live is going to hit you CPU wise, you're going to take a 20-40% CPU hit using those DAWs not matter how you adjust your workflow.

[machinesworking]

another aspect that would be interesting to include a test comparison would be to actually measure the latency on both systems to make sure that comparative results are based on getting the same latency. This is because DAW's can sometimes add extra safety buffers...which increases the work they can do, but also the latency. A true comparison will be like for like. Everything as much the same as possible. Same buffer size (or rather, same settings that achieve the same RTL), same plugins, same tracks, etc.. with same resulting output, which would be clean audio no drop outs, same latency, same sample rate, etc..

Sticking with same buffer size is imperative, any DAW will kick any other DAWs ass if it's at 2048 while the other is at 64.
The rest, no, I don't think so. First off how do you measure the comparative latency of a soft synth? What you're asking is literally only going to be milliseconds differences in the time it takes the tracks to simultaneously play when you hit the spacebar.

If DAW X is giving me 1/16th of a second latency from spacebar to audio VS DAW Y which is only giving 1/32nd, I'm not punishing DAW X for giving higher track counts at the same buffer settings, on the contrary. This is exactly the area that I suspect Logic is using to get decent track counts compared to DP and others that use pre rendering.

[machinesworking]

Totally agree with machinesworking. Coming from an (electronic as well as sound) engineer background a stress test means throw everything at it that it will take ‘til it tips over (too intense too stay under pressure) or some such term. Stress in this case means fault. When it stops working.

Thanks. Essentially it's all about knowing your system, and I see no pride in knowingly or unknowingly artificially manufacturing numbers that make your DAW look the best.

DAWs aren't race cars, you don't get songs finished quicker because you get an extra instance of a plug in out of your DAW. But knowing what your system can handle is super useful.

I loaded two Cinesample heavily scripted libraries into one instance of Kontakt and killed my CPU, but loading 12 cinesamplel libraries across 12 instances of Kontakt and I only get a reading of 60% on the CPU. These are the kinds of things people need to be aware of. That record enabling tracks in a DAW puts that track into "real time" takes out that extra buffering most DAWs are doing and takes out the pre rendering that DP and Reaper seam to be doing.

It's all just information, and it's useful.

[Dewdman42]

another aspect that would be interesting to include a test comparison would be to actually measure the latency on both systems to make sure that comparative results are based on getting the same latency. This is because DAW's can sometimes add extra safety buffers...which increases the work they can do, but also the latency. A true comparison will be like for like. Everything as much the same as possible. Same buffer size (or rather, same settings that achieve the same RTL), same plugins, same tracks, etc.. with same resulting output, which would be clean audio no drop outs, same latency, same sample rate, etc..

Sticking with same buffer size is imperative, any DAW will kick any other DAWs ass if it's at 2048 while the other is at 64.

No. The imperative is to achieve the same RESULTS. Each DAW should be setup to acheive the same latency result...whatever buffer size is required to do that. Otherwise its not fair comparison of performance.

Cubase can say the buffer size is one thing but if it adds 10ms of latency with ASIO guard, then its not a fair comparison against another daw without that added latency. You cannot just look at the buffer size alone if you want to make a fair comparison, you have to look at the latency you expect to achieve..and should use whatever controls are available in each DAW to configure it for that same latency number amount..which may involve secret extra buffers internally or may not..but its irrelevant.

If DAW X is giving me 1/16th of a second latency from spacebar to audio VS DAW Y which is only giving 1/32nd, I'm not punishing DAW X for giving higher track counts at the same buffer settings, on the contrary. This is exactly the area that I suspect Logic is using to get decent track counts compared to DP and others that use pre rendering.

You are punishing DAW's if you compare them with the same basic buffer size, but one is allowed to have a lot more latency then the other while doing it. That is not a fair comparison.

[Iva]

Cubase can say the buffer size is one thing but if it adds 10ms of latency with ASIO guard, then its not a fair comparison against another daw without that added latency. You cannot just look at the buffer size alone if you want to make a fair comparison, you have to look at the latency you expect to achieve..and should use whatever controls are available in each DAW to configure it for that same latency number amount..which may involve secret extra buffers internally or may not..but its irrelevant.

what if I tell you that some DAWs and even audio interface manufactures are actually lying you about real latency they produce (including apple company) vs latency shown in their settings page? if u keep that in mind, the real comparison would be all about daw performance, not latency.

for example:

RME Multiface
driver: 64 samples 1.45 sec
result: Measurement results: 225 samples / 5.10 ms
driver: 128 (2.90sec)
Measurement results: 353 samples / 8.00 ms
driver: 256 (5.80sec)
Measurement results: 610 samples / 13.83 ms
driver: 512(11.61msec)
Measurement results: 1121 samples / 25.42 ms

[Ploki]

Cubase can say the buffer size is one thing but if it adds 10ms of latency with ASIO guard, then its not a fair comparison against another daw without that added latency. You cannot just look at the buffer size alone if you want to make a fair comparison, you have to look at the latency you expect to achieve..and should use whatever controls are available in each DAW to configure it for that same latency number amount..which may involve secret extra buffers internally or may not..but its irrelevant.

what if I tell you that some DAWs and even audio interface manufactures are actually lying you about real latency they produce (including apple company) vs latency shown in their settings page? if u keep that in mind, the real comparison would be all about daw performance, not latency.

for example:

RME Multiface
driver: 64 samples 1.45 sec
result: Measurement results: 225 samples / 5.10 ms
driver: 128 (2.90sec)
Measurement results: 353 samples / 8.00 ms
driver: 256 (5.80sec)
Measurement results: 610 samples / 13.83 ms
driver: 512(11.61msec)
Measurement results: 1121 samples / 25.42 ms

what if i tell you're comparing single end numbers to roundtrip latency?

[Dewdman42]

The test should be all about DAW performance, exactly. The DAW needs to perform with the same RTL, same sample rate, same plugins, same track data, same sound coming out the speakers (either both clean or both are just at the first noticed point of clicks and pops). What a given DAW can do on a given machine, with the same performance outcome, is a true comparison...that outcome includes the latency actually achieved.

To be absolutely correct, you would need to also measure RTL using a cable loopback test THROUGH THE DAW. I think that would be a PITA frankly, so we could start with just assuming the soundcard and DAW's are reporting it accurately for now. To do it properly you'd need to actually measure the RTL, through the DAW, using a cable loopback method.

And what Ploki said...

So the soundcard will report several numbers. It will report input latency, output latency and a safety offset buffer, which might be zero in some cases. The DAW will add those up and also if its adding any more latency of its own, will add that to the number as well and should report you the latency of the system and it should be pretty close. Where it will definitely be wrong is if you have external digital audio communication between devices..like if you're using MADI or AES50 or ADAT or some other protocol to connect several interfaces together before hitting the computer through one, then some of them may have a little bit extra unreported latency ...which the DAW will not be able to know about or report. There is always a possibility that a DAW simply not reporting it accurately for any other reason, so to be completely accurate you'd need to measure the RTL through the DAW itself at each configuration tested.

[machinesworking]

another aspect that would be interesting to include a test comparison would be to actually measure the latency on both systems to make sure that comparative results are based on getting the same latency. This is because DAW's can sometimes add extra safety buffers...which increases the work they can do, but also the latency. A true comparison will be like for like. Everything as much the same as possible. Same buffer size (or rather, same settings that achieve the same RTL), same plugins, same tracks, etc.. with same resulting output, which would be clean audio no drop outs, same latency, same sample rate, etc..

Sticking with same buffer size is imperative, any DAW will kick any other DAWs ass if it's at 2048 while the other is at 64.

No. The imperative is to achieve the same RESULTS. Each DAW should be setup to acheive the same latency result...whatever buffer size is required to do that. Otherwise its not fair comparison of performance.

Cubase can say the buffer size is one thing but if it adds 10ms of latency with ASIO guard, then its not a fair comparison against another daw without that added latency. You cannot just look at the buffer size alone if you want to make a fair comparison, you have to look at the latency you expect to achieve..and should use whatever controls are available in each DAW to configure it for that same latency number amount..which may involve secret extra buffers internally or may not..but its irrelevant.

If DAW X is giving me 1/16th of a second latency from spacebar to audio VS DAW Y which is only giving 1/32nd, I'm not punishing DAW X for giving higher track counts at the same buffer settings, on the contrary. This is exactly the area that I suspect Logic is using to get decent track counts compared to DP and others that use pre rendering.

You are punishing DAW's if you compare them with the same basic buffer size, but one is allowed to have a lot more latency then the other while doing it. That is not a fair comparison.

You're really stretching things here. Plus you're not going to be able to get the information you need on all DAWs, for what it's worth I think Reaper is the only DAW out of the 4+ I own that actually reports the latency of the individual plugins. Claiming that buffer latency settings aren't accurate is just.. a never ending spiral of unsubstantiated doubt.

What matters, and will always be what matters, is the latency a DAW has on a track you are currently trying to play audio or midi into. This is directly related to the buffer settings. No DAW test should ever be done with different buffer settings because some end user believes X DAW is "cheating".

Basically you're cheating the test if you:

Don't do it to the limits of your computer (to failure, then backed off until stable)

Set different sample rates, buffer settings.

Have different plug ins in different DAWs for the same test.

Choose to disable whatever scheme that DAW uses to get extra CPU out of the DAW, i.e. PreGen, Adaptive FX processing, etc.

We're not trying to distill a test down to binary 1's and 0's here, we're trying to determine which DAW with the same buffer settings (giving obviously the same latency on record enable tracks), using whatever methods don't make composing impossible, is the most CPU efficient. It's why I've never seen a test done at a buffer setting of 2048.

[Dewdman42]

I didn't say anything about plugin latency. Plugin latency should be the same regardless of the DAW. Plugin latency has nothing to do with anything I said above, I'm not sure why you're mentioning that now.

You can do a RTL loop back test with any DAW, any time and that will tell you exactly what the RoundTripLatency is...without any plugins..

Cubase gives various numbers...I have not tested it with loopback to find out if its accurate. I have tested LogicPro and its accurate with the audio devices I use.

[Dewdman42]

You're really stretching things here.

I think you are.

Plus you're not going to be able to get the information you need on all DAWs,

You can perform a loop back test on any daw and find out exactly what the actual Round Trip Latency is.

for what it's worth I think Reaper is the only DAW out of the 4+ I own that actually reports the latency of the individual plugins.

LogicPro will tell you the latency of each plugin by floating the mouse over the plugin buttons of each one, but does not display a grand total, but it does not matter, this has nothing to do with this test or anything that I suggested above.

Claiming that buffer latency settings aren't accurate is just.. a never ending spiral of unsubstantiated doubt.

Sometimes they are not accurate. This mainly can happen if you have external digital gear as I explained above. I have found all of my audio devices to be accurate in terms of what the driver reports. But that is still missing the point MW..

The point is that cubase adds extra buffers to do ASIO Guard. I'm not sure what Reaper does. The actual round trip latency experienced by the user is what matters and that needs to be the same in any kind of comparison test, for it to be meaningful.

What matters, and will always be what matters, is the latency a DAW has on a track you are currently trying to play audio or midi into. This is directly related to the buffer settings. No DAW test should ever be done with different buffer settings because some end user believes X DAW is "cheating".

No. Cheating is if you compare two DAW's using different latencies. ASIOGuard, for example, adds latency through additional buffers. That is cheating unless you enlarge the buffer on the other comparison DAW's until they are at the same latency.

Basically you're cheating the test if you:

Don't do it to the limits of your computer (to failure, then backed off until stable)

no that is not cheating, that is simply a different set of useful data that MW doesn't like to pay attention to, but other people do.

Set different sample rates,

yes

set different buffer settings.

no. See above.

Have different plug ins in different DAWs for the same test.

yes

Choose to disable whatever scheme that DAW uses to get extra CPU out of the DAW, i.e. PreGen, Adaptive FX processing, etc.

That depends, but generally I agree. If you enable a feature that increases the latency than that is cheating unless you ensure the other DAW's get an expanded buffer also. I agree with you that Pre-Gen technology should be included in a comparison. However, another useful test can and should be to compare live modes of each DAW...which will not be able to take advantage of pre-gen technologies.

We're not trying to distill a test down to binary 1's and 0's here, we're trying to determine which DAW with the same buffer settings (giving obviously the same latency on record enable tracks),

This is where you're wrong. The same buffer settings will not always give the same latencies because extra features like ASIO guard add extra buffers and latency in a hidden way. You have to adjust the settings so that the latency is the same in all cases. In many cases they very well may have the same buffer size, but in some cases not.

using whatever methods don't make composing impossible, is the most CPU efficient. It's why I've never seen a test done at a buffer setting of 2048.

All latency settings are interesting data. Large buffers for mix down and small buffers for tracking, where in particular, "live" mode matters more as well.

[machinesworking]

We're not trying to distill a test down to binary 1's and 0's here, we're trying to determine which DAW with the same buffer settings (giving obviously the same latency on record enable tracks),

This is where you're wrong. The same buffer settings will not always give the same latencies because extra features like ASIO guard add extra buffers and latency in a hidden way. You have to adjust the settings so that the latency is the same in all cases. In many cases they very well may have the same buffer size, but in some cases not.

The part in bold. I couldn't care less about non record enabled tracks, and if Cubase or whatever DAW does it, is getting more latency from non record enabled tracks but with the same buffer settings (time) on record enabled tracks they deserve a prize not a penalty flag.

Just so we're on the same page here, if ASIO guard is messing up live input from audio ins, or messing up soft synths in terms of playability at the "same" buffer settings, then I get what you're saying, but if the miliseconds of delay on external instruments and soft synths is the same as other DAWs at the same buffer settings then I'm all for it.

This is some splitting hairs stuff though requiring real testing, I mean I doubt it's as bad as say 128 being the latency of 512, and if they were cheating to a huge degree, other DAW manufacturers would point it out eventually.

MOTU claimed when DP9 hit that 256 would now feel like 128, so sort of doing the opposite, saying they improved their latency at the same buffer settings. Just to make this all more confusing for us end users..

[jancivil]

... take any 'results' with a cup of salt.

I was curious about the relative CPU efficiency of Studio One & Cubase, as compared to Logic & Pro Tools which are the main DAW's I use.

I was curious about the "active load" for my typical use.

[...][...][...][...] with regards to CPU usage.

Except choosing a DAW software (or any software for that matter) based on anything other than the roles it fulfills for your needs, is pointless. If you find yourself pegging out in one of the many potential bottlenecks, eliminate the bottleneck.

Success with a computer DAW is down to realtime performance, rather than CPU efficiency; ie., you have bottlenecks which bely your CPU specs/usage. Tends to be a device which is causing things to be interrupted/wait in line.

Cubase for me is not using a lot of cycles; but NB this is down to hosting 99% of plugins in VE Pro, which uses cores fairly well. And the notion of using other hosts to me, a waste of time since I have a steady workflow the way things are. So, sure, one supposes Logic is super-efficient, only its integration with VE Pro is far from optimal and those of us who use that, and require it may tend towards less attraction.

There is no abstract objective consideration to be had really, because systems are complex and not uniform.

[Guenon]

You are punishing DAW's if you compare them with the same basic buffer size, but one is allowed to have a lot more latency then the other while doing it. That is not a fair comparison.

From what I've read in this thread, you didn't quite understand what anticipative processing does. Maybe you already do know better, now , but just in case someone comes here for info on this: machinesworking is the one who makes sense here, and yep, anticipative processing doesn't have an effect on the round trip latency, as it merely starts processing everything in advance that isn't armed for realtime recording/performing. When you have something armed, and then you measure actual RTL on the armed track(s), you will have an identical realtime round trip as with anticipative processing off - only with significantly more efficient use of computing resources for the playback of the whole project at the same time.

In other words, imagine all the tracks that you aren't recording/performing on, and automatically moving them slightly ahead of time before starting playback. Not the armed track(s), just everything else. When you hit play, everything that has been nudged ahead of time starts rendering - yes, in a longer buffer of their own, as there is a (very) slight pause before you hear the result (i.e. audible playback starts) - and the very short pause right at the start of playback is the only "added delay" in the audio you encounter. Your armed tracks will be completely in sync with the ones that already started rendering a short moment ago but effectively were also moved ahead of time by that amount, and when you perform, your performance will be recorded at the correct position in relation with the non-armed tracks, and you will still have the exact same actual realtime latency for recording/performing as before.

Combining anticipative processing with the driver quality of the RME HDSPe AIO, I can run pretty insane track/plugin amounts and still have pretty insanely short realtime latencies at the same time, for performing new parts even when projects grow and grow (too much) . From my point of view, there really hasn't been a downside.

[Dewdman42]

Yes I understood what it meant and I stand by everything i said. All the tests matter, including live tests (which Reaper's anticipative Processing would not help), and non-live mixing tests...max out and non-max out..

[Guenon]

Personally, I look at it from the perspective of the composer/producer who gets commissioned to turn in finished tracks, and most of the time real-world projects of that nature are a combination of playing back the rest of the project while also realtime recording/performing on some select track(s) at the same time. I'm not too keen on freezing, and still want to be able to keep the actual performance latency very low in order to improvise on any instrument as I see fit, even as the project grows.

There's a danger I'm looking at it too subjectively , but I'd hazard a guess a great number of DAW projects evolve in some comparable fashion, i.e. there's a growing amount of tracks with material on them, going into a (large or small) number of downstream plugins, yet most of those tracks also aren't actively being performed on or recorded on at any single moment, and they are just playing back what's there, while only one (or only a few) track(s) are being performed on.

What actually matters in cases like this, in order to get the work done, is the actual amount of stuff the DAW software and the whole DAW system can run, and still keep realtime performance latency where it was - as low as you want it to be in order to be able to perform - before running out of steam. In other words, what the failure point of the whole is, and can it be alleviated with some feature/technique that doesn't compromise realtime latency. Anticipative processing does this, and again, from the perspective of real-world projects where you weigh the capacity and possibilities of your system in these terms, the effect it has is practically synonymous with "more efficient."