What's new

DAW Performance Test Results

Well don’t use that big of a buffer of course! It’s all relative. The point of this test was to compare daws, not to see what my system is capable of. I would expect to see worse cpu performance as you lower the buffer setting. I reckon the daws would compare about the same to each other regardless of the buffer setting but it would be an interesting test to rerun all the tests on all the daws with lower buffer size to see, unfortunately I’m burned out on running the tests so I leave that to someone else to try
 
This is a great read.

Coincidentally, the 3 Windows based DAWs I have settled in with are,

Studio One Pro, Cubase Pro, and Reaper.

I feel your pain about Reaper.

I've had it for years and never bonded with it.

Until recently I fired it up with a Logic theme.

Now Reaper is the first DAW i reach for - as i mentioned in another thread, I've always suffered from Logic-Envy.

Thanks for all the work.
 
So, is the Reaper Performance Meter not telling the full story?

What are the Reaper Heads saying about these results?

Their huge push for Reaper being the end-all DAW was always performance over other DAWs.

This flies in the face of that.
 
The cpu results are being obtained at the system level, not within the daws themselves. They show the average overall cpu performance happening while playing back the exact same vsl-based project for 3 minutes and getting the average cpu across all cores every 3 seconds.
 
And yes, at least on Mac reaper did not compare well but it’s also possible that there are performance settings in reaper that I need to learn about.
 
FWIW, i noticed a significant "apparent" CPU improvement with Studio One 4.5 over the previous 4.1.1 (i think).
 
New test added for Reaper5 without VEP. slighter better performance without VEP this time. I presume this is because of Reaper's render-ahead. DP is the other daw that also performs slightly better without VEP, which also has their "pregen" render-ahead technology. See original post for details
 
Interesting. But 1024 is a pretty large buffer - what VI Pro buffer did you have? Assuming it's 1 buffer then your total latency is 2048, which is really large for modern hardware. I'm also assuming you're running at 44.1 or 48 kHz (maybe you said...).

I bet if you tested down to buffers where you start getting dropouts that you'd see different results. What you showed is that except for Cubase w/o VE Pro, all the DAWs can run the project just fine at 1024 buffer.

But which ones can run at 96? Which at 128? Etc. I think that's a more useful measurement.

rgames

I agree here. 1024 is really not a good value to test performance. This value doesn’t tell you anything, because the system is not put under strain. Under heavy CPU load it shows which DAW can really take the load and how it behaves. 256 would be a more realistic buffer, especially for composing.

Just my 2 cents...
 
it is, but I wouldn't use 128 or 64 for composing. 256 is a more practical value to work with. Of course you could additionally provide 128 and 64 just to see how it compares.
 
Did a new test, this time using LPX with one VEP instance per instrument track.

Drum Roll....

It performs similar performance as other LPX tests, but of the three main LPX tests I did, its the worst, but only by 1% difference, so really this should only be a workflow decision. Here's some data and a new chart comparing three modes of usage with LPX..

pubchart


  1. LPX+VEP+instance-per-instrument: 25% average cpu
  2. LPX alone: 25% average cpu
  3. LPX+VEP-AU3 (single instance): 24% average cpu

As a side note, it took me 2-3x as much time to setup this test, I found the single VEP instance per track to be entirely a PITA in the setup and very laborious to do so. At one point I had to manually reconnect 90 VEP plugins to their various instances on top of it all. Anyway, workflow is different for everyone, the point of this test is to compare performance I would say it does not really make much difference which approach in terms of performance. Use the approach that works best for your workflow.
Hi
I know this is an old thread, but still important. What you say here is that your piece of music - was 90 tracks - all routed to VEPro on the same machine with one instance pr. track is only about 1% "heavier" in CPU load than if the patches in VEPro was concentrated on few instances?
Wouldn't you say that the benefits from "one track - one instrument" would justify this 1 %?
 
No I do not think cpu performance should be a contributing factor as to whether you use one track per instrument or not. Ita a workflow decision. By the way, one track per instrument was worse performance then using one single instance! You had that backwards. But only by 1%, which is not a big enough difference to justify a change for that reason alone.
 
I know it performed worse, but I consider the other benefits of having one track one instrument. As of now I have a big orchestral perc. instance on slave 2 with around 40 instruments, many of them I rarely use. If I have them all as track/instr. in Logic AND couple VEPro, they will only be activated on the slave the moment I need them and turn them on in Logic, the rest of the time they will be turned of and hidden, and it’S hardly noticeable on the filesize in Logic Seems so much simpler that way, right?
 
That’s a workflow decision and perfectly valid. But performance is not a justifiable reason to use one track per instance.

There are workflow pros and cons either way
 
I know it performed worse, but I consider the other benefits of having one track one instrument. As of now I have a big orchestral perc. instance on slave 2 with around 40 instruments, many of them I rarely use. If I have them all as track/instr. in Logic AND couple VEPro, they will only be activated on the slave the moment I need them and turn them on in Logic, the rest of the time they will be turned of and hidden, and it’S hardly noticeable on the filesize in Logic Seems so much simpler that way, right?

Yeah, I've always used one instance per instrument and never noticed a difference in performance compared to combined instances.
 
Top Bottom