KVR Audio

Peter999 · Post by **Peter999** » Thu Jun 07, 2012 8:20 pm

MFXxx wrote:
MFXxx wrote:CPU i7 2.66ghz Factory Clock / 12GB Triple 1600mhz / SSD 120GB + WD Raptor

Cubase 6.5.1 x64 / Win7 x64

RME FF800 @ 128 Samples

Between 22% - 36% CPU peak -> 27-29% CPU Visual Average

Nice work.

DIdnt close a lot of other apps in the beground (being lazy today and just playing).
Reaper 4 .22 x64

Between 9% - 18% CPU peak -> 12-14% CPU Visual Average

Live 8.2.5 x32 14-22 CPU Peal -> 16-18% CPU Visual Average

interesting - reaper x64 more performant than cubase x64 and live x32? really must check it out too...

MFXxx · Post by **MFXxx** » Thu Jun 07, 2012 9:26 pm

Peter999 wrote: interesting - reaper x64 more performant than cubase x64 and live x32? really must check it out too...

I thought the same so rerunning

Cubase 6.5.1 x64 rerun 14 - 24 average 19-22 CPU Visual... ASIO flickering around 50% bar.

Peter999 · Post by **Peter999** » Fri Jun 08, 2012 5:04 pm

Just tested by myself. Indeed Reaper x64 has the better performance than Cubase in 32 bit!

Reaper v4.22 x64
Windows 7 Professional 64 Bit

Intel Core i7 920 @ 2,66 GHz
RME HDSP 9632 @ 256 samples

21 instances of OP-X PRO-II (version 1.1)

The CPU meter in the windows task manager never exceeded 10%.
The Reaper performance meter shows about 20%.
Session loading time 22 seconds.

So no reason at all not to run it in 64bit really. Uses less ressources than unbridged in Live or Cubase.

---

kbaccki · Post by **kbaccki** » Fri Jun 08, 2012 5:29 pm

Peter999 wrote:Just tested by myself. Indeed Reaper x64 has the better performance than Cubase in 32 bit!

Reaper v4.22 x64
Windows 7 Professional 64 Bit

Intel Core i7 920 @ 2,66 GHz
RME HDSP 9632 @ 256 samples

21 instances of OP-X PRO-II (version 1.1)

The CPU meter in the windows task manager never exceeded 10%.
The Reaper performance meter shows about 20%.
Session loading time 22 seconds.

Disable "Anticipative FX processing" and rerun your test. I think it applies to all FX processing, including VSTi, realtime, etc.

Peter999 · Post by **Peter999** » Sat Jun 09, 2012 9:21 am

I only can see such an option for rendering to disk. What's the effect of this?

Peter999 · Post by **Peter999** » Sat Jun 09, 2012 3:13 pm

The same in full view:

---

Pinocchio · Post by **Pinocchio** » Sat Jun 09, 2012 3:41 pm

--

Using WinXP SP3 and Reaper 4.22 32bit
Intel i5-750 locked at 3100mhz and 4GB RAM

ASIO4All at 512 samples = max 20%
(in Task Manager with OP-X PRO-II Demo and 21 instances)

But session loading time was 2:30min

--

Peter999 · Post by **Peter999** » Sat Jun 09, 2012 3:53 pm

Yep, obviously loading is quite a bit slower in XP, must be OS related somehow.

In Windows 7 Professional 64Bit it's only 22 seconds.

---

kbaccki · Post by **kbaccki** » Sun Jun 10, 2012 5:14 pm

Peter999 wrote:I only can see such an option for rendering to disk. What's the effect of this?

I could be wrong but I believe Anticipative FX is disabled automatically when monotoring a record-armed track (because you want FX to be processed realtime, obviously), but for playback/render it is enabled unless explicitly disabled. Things may have changed a bit over the last couple of years...

You could try this just to be sure... load up your project, then right-click each synth track => Track performance options => Prevent anticipative FX, run for 10-20 seconds. If the CPU load looks the same then FX lookahead apparently does not apply to VSTi playback... I have a feeling it does, though, and you might see a bit of a bump in overall CPU usage by processing strictly realtime.

Peter999 · Post by **Peter999** » Mon Jun 11, 2012 2:50 pm

But will this bring an advantage over the standard setting?

kbaccki · Post by **kbaccki** » Mon Jun 11, 2012 4:59 pm

Peter999 wrote:But will this bring an advantage over the standard setting?

If anticipative FX is active during playback, then it should lower averall CPU usage. Anticipative FX amounts to lookahead processing -- rather than process this current 3ms chunk of MIDI/audio, process the next 30ms of MIDI/audio. You're effectively increasing your buffer to that lookahead amount… however many ms that is. The nice thing about it is that you can be smart about the lookahead such that arm-recorded tracks will NOT be processed in that way, so that you get true "realtime" processing on those, but all other track swill be processed via lookahead (unless you "dirty the cache", as it were, by modifying some params "out of band" , thereby forcing the engine to throw away what it precomputed)… make sense? Again, depends on whether or not VSTi in playback mode go through Anticipative FX processing, which I think they do...

Peter999 · Post by **Peter999** » Wed Jun 13, 2012 8:45 am

Ah I see - seems to be a pretty clever feature. But I can't see a reason to switch it off, since in armed tracks it's automatically de-activated for strict real-time operation.

kbaccki · Post by **kbaccki** » Wed Jun 13, 2012 12:41 pm

Peter999 wrote:Ah I see - seems to be a pretty clever feature. But I can't see a reason to switch it off, since in armed tracks it's automatically de-activated for strict real-time operation.

Useful, yes… my point is that it's a performance optimzation, so it skews your CPU usage results. For example, if you say Reaper @ 256 sample buffer clocks in at 20% CPU while Cubase @ 256 sample buffer clocks in at 30% CPU, therefore Reaper is better, keep in mind you're testing apples and oranges. The apple is actually at an effecive latency of, say, 1024 samples, not 256 samples, while the orange really is at 256 sample latency. So the CPU usage will be lower for Reaper w/ Anticipative FX turned on. That's the whole point of Anticipative FX, it lowers CPU usage! In general, increasing the procesing buffer size lowers CPU, until you hit a threshold and start seeing performance degrade due to large buffer sizes (at some point it costs more to manage the larger chunks of data)… so there's a performance sweet spot with latency buffer sizes, and Anticipative FX aims to take advantage of that.

An apples to apples performance test would involve turning off Anticipative FX entirely in Reaper, and in DAW "B" doing the same… just guarantee that when you say both are @256 samples latency, that both truly are operating at 256 samples latency for all processing. For example, I know Samplitude has a "hybrid engine", which AFAIK gives you the same exact effect of Anticipative FX… Some selection of Samplitude tracks are literally "real time", while all others perform lookahead pre-caching of processed WAV data. Does Cubase have the same type of buffering/preloading/precaching scheme? I don't think it does, but I do know that SONAR does not.

Peter999 · Post by **Peter999** » Wed Jun 13, 2012 1:50 pm

I completely agree. This btw was not thought as a DAW shootout, just as a general performance test that can be repeated in the own system. For a fair DAW shootout all of this of course should be paid attention to. In fact I personally don't reallly care about a bit more or less CPU load, the times really are over when this was the main issue. What's important for me in a DAW is the workflow, the features and the stability. Regarding workflow everyone has its own personal preferences.

kbaccki · Post by **kbaccki** » Thu Jun 14, 2012 12:08 am

Peter999 wrote:I completely agree. This btw was not thought as a DAW shootout, just as a general performance test that can be repeated in the own system.

Agreed. I was only responding to some of the earlier (somewhat generic) posts comparing performance of Reaper vs. Cubase, etc. In terms of straight performance (i.e., not apples-to-apples "audio engine" tests) Reaper does have the clever lookahead processing, which should ease up on the CPU compared to a DAW that doesn't precompute. Basic audio engine handling of VST/VSTi/threading/etc. will also affect performance, of course. I think what we've discovered here is that Reaper + OP-X Pro II = WINNING COMBINATION!

OP-X PRO-II: 21 Instances performance demo session - video and free download - 50% load in Core2duo!