Go Back   Cockos Incorporated Forums > REAPER Forums > REAPER General Discussion Forum

Reply
 
Thread Tools Display Modes
Old 08-04-2016, 06:07 AM   #1
seymour22
Human being with feelings
 
seymour22's Avatar
 
Join Date: Nov 2013
Posts: 112
Default Multicore HW from Reaper's sense of view

Dear all,
which kind of logic is more efficient while working with Reaper's DAW:

4 core of 3,7 GHz 10 MB L3 cache or

12 core of 2,7 GHz 30 MB L3 cache

?

Kind regards
Tom.kw
seymour22 is offline   Reply With Quote
Old 08-04-2016, 06:23 AM   #2
eternoob
Human being with feelings
 
Join Date: Apr 2016
Location: Old Europe
Posts: 14
Default

I noticed that Reaper seems to distribute its load quite evenly over all available cores, so more cores are probably useful. But still I don't think I would buy a 12 core machine with only 2,7GHz. How about 6 cores >3GHz?
:-p
eternoob is offline   Reply With Quote
Old 08-04-2016, 07:01 AM   #3
mgmchenry
Human being with feelings
 
Join Date: Jan 2015
Posts: 18
Default

If it were me, right now, I'd buy something I could overclock to at least 4Ghz.

Some parts of reaper multithread well. I do live mixing and need very low latency. I use amplitube on some tracks, and it only runs on the audio thread. If my CPU utilization goes over 10℅, I can start to hear pops.

Raw single core low latency speed is what I need. I would be better off with a single 4.x GHz core than a twelve core 2.7 GHz box.

If you're not working in real time... I don't think it matters that much. Modern computers are so fast, it just doesn't matter.
mgmchenry is offline   Reply With Quote
Old 08-04-2016, 07:01 AM   #4
Softsynth
Human being with feelings
 
Join Date: Jun 2015
Posts: 8,696
Default

The higher clock speed processor willl outperform the greater core number processor most of the time.
Many VSTi's are still not even optimized for multi core.
Softsynth is offline   Reply With Quote
Old 08-04-2016, 07:23 AM   #5
eternoob
Human being with feelings
 
Join Date: Apr 2016
Location: Old Europe
Posts: 14
Default

Quote:
Originally Posted by Softsynth View Post
Many VSTi's are still not even optimized for multi core.
Then again, a VSTi wouldn't gain much by trying to split its load into many threads (except from syncronisation problems...). I'd think that it's mostly up to the DAW to organize reasonable threading.
eternoob is offline   Reply With Quote
Old 08-04-2016, 07:52 AM   #6
karbomusic
Human being with feelings
 
karbomusic's Avatar
 
Join Date: May 2009
Posts: 29,260
Default

The biggest thing to be aware of is the Real time CPU thread which owns the handle to the audio driver, it can only live on a single thread which means a single core. You could have 5000 cores and the RT thread/core be maxed out causing pops/clicks.

And the obligatory YT video on the subject in general...

https://www.youtube.com/watch?v=GUsLLEkswzE
__________________
Music is what feelings sound like.
karbomusic is offline   Reply With Quote
Old 08-04-2016, 09:45 AM   #7
endorka
Human being with feelings
 
endorka's Avatar
 
Join Date: Jan 2014
Location: Glasgow
Posts: 521
Default

I understand the theory, and the possibility of single tasking bottlenecks, and with that in mind, the benefits will depend on your typical usage pattern.

I can only offer an analogy since my music system is old. Last year I upgraded from an AMD Athlon 64 X2 dual core to AMD Phenom Quad Core. It was the most powerful CPU I could fit into the motherboard.

The quad clock is a little slower than the dual, so it was a bit of a gamble. But performance significantly increased; projects that will struggling on the dual were working no problem on the quad, and using the dual allowed me to postpone the dreaded new computer/reinstall software time sink for another year or two.

Of course the technology you are speaking of is way ahead of this, so YMMV. Also I tend to use several virtual instruments over several tracks in most of my projects, so the boost may be specific to this scenario.

Good luck, and I'd be interested to hear about the outcome.

Jennifer
__________________
Producer | Arranger | Composer | Bass guitar | Double bass
Website: https://www.jenclarkmusic.com/
endorka is offline   Reply With Quote
Old 08-04-2016, 10:04 AM   #8
serr
Human being with feelings
 
Join Date: Sep 2010
Posts: 12,557
Default

I have an 8 core 2.93GHz i7 Xeon machine. (Turbo boost 3.33GHz)

I'll max out a single core first with audio work in Reaper.
Now, I have to have a large studio mix project with well over 200 tracks and just as many plugins up before anything gets close to maxed out. It also helps to have a couple known buggy plugins in use.

Anything less (including live sound work) and the thing just idles.

Looks like shopping CPU speed before # cores is still proper advice.
As mentioned, the RT CPU thread can't be split up. When that one hits max it's game over no matter how many cores you still have free.


There's got to be a line somewhere though if we start comparing 10 year old C2D CPUs to more modern i7's.

One thing I don't really do is play with the MIDI instruments. I understand there are a few gargantuan resource hogs available these days with 147 samples for each note, convolution dynamics modeling, and probably something else I'm not even aware of. Not sure how these play out.

Last edited by serr; 08-04-2016 at 10:11 AM.
serr is offline   Reply With Quote
Old 08-05-2016, 04:40 AM   #9
seymour22
Human being with feelings
 
seymour22's Avatar
 
Join Date: Nov 2013
Posts: 112
Default

Thank you for all your impresive answers!
Awesome!

I think I would be in the middle of nowhere with no them...

In fact the RT & low latency is crucial for what I do in my studio.

So, righ now some last battle:

4 cores of 3.7 GHz (Mac Pro architekture) vs

4 cores of i7 4.0GHz (up to 4.2GHz) iMac ?

That seems to be tricky question. Both have different architekture.... but who knows (?)

Do you have any clue?

Thank you!!!
Tom.kw
seymour22 is offline   Reply With Quote
Old 08-05-2016, 06:12 AM   #10
snooks
Banned
 
Join Date: Sep 2015
Posts: 1,650
Default

Quote:
Originally Posted by mgmchenry View Post
I do live mixing and need very low latency. I use amplitube on some tracks, and it only runs on the audio thread. If my CPU utilization goes over 10℅, I can start to hear pops.
Have you tried....

Preferences->Buffering->Allow live multiprocessing on X CPUs

...? Although it says that it "may reduce performance at low latencies", that's not the case here - down to a 24 sample buffer. In fact it massively increases the amount of live monitored FX I can use. This is with a PC laptop running Windows... it might not have as much as an effect on Mac OSX (or Bootcamp Windows) though because of the Mac EFI.

It's always worth playing with the "Thread priority" and "Behavior" settings too.
snooks is offline   Reply With Quote
Old 08-05-2016, 05:20 PM   #11
keyman_sam
Human being with feelings
 
keyman_sam's Avatar
 
Join Date: Jun 2006
Posts: 2,562
Default

Quote:
Originally Posted by seymour22 View Post
So, righ now some last battle:

4 cores of 3.7 GHz (Mac Pro architekture) vs

4 cores of i7 4.0GHz (up to 4.2GHz) iMac ?

That seems to be tricky question. Both have different architekture.... but who knows (?)

Do you have any clue?

Thank you!!!
Tom.kw
A reputable audio DAW builder suggested that the iMac is the fastest Mac you can get (beating even the Mac Pro) for audio.
__________________
The must-have sample library for shortcircuit :
Essentials Volume 1
http://forum.cockos.com/project.php?...3313#note14891
keyman_sam is offline   Reply With Quote
Old 08-08-2016, 09:43 AM   #12
seymour22
Human being with feelings
 
seymour22's Avatar
 
Join Date: Nov 2013
Posts: 112
Default

Ok, so I guess all those Mac Pro - Reaper users went to their vacation

To those of you who use i7 quad-cores iMac: any problem around noisy cooling? Would you share disadvantages?

I am still not convinced which way is correct one for me. Banchmarks say iMac i7 Has best reponse times. Sellers say iMac is a toy far away behind Mac Pro.

I would be grateful hearing from those have been using both Wit Reaper on board.

Any there?

Kind regards
Tom.kw


Quote:
Originally Posted by keyman_sam View Post
A reputable audio DAW builder suggested that the iMac is the fastest Mac you can get (beating even the Mac Pro) for audio.
seymour22 is offline   Reply With Quote
Old 08-08-2016, 09:50 AM   #13
serr
Human being with feelings
 
Join Date: Sep 2010
Posts: 12,557
Default

Quote:
Originally Posted by keyman_sam View Post
A reputable audio DAW builder suggested that the iMac is the fastest Mac you can get (beating even the Mac Pro) for audio.
Kind of absurd. The Mac Pros are the top spec machines. They have better cooling and are made to run at 100% 24/7.

When you want a tool that does that, that's what you buy.

Nothing against the iMac either. When you want a computer and display in the same box and the specs of the computer part meet your needs, the iMac can be the more efficient choice. Doesn't make it faster than the Mac Pro that you didn't need the extended capabilities of and thus didn't want to pay extra for.

That combo design choice happens to make the iMac the most expensive to repair or mod. Worst choice fit for a DAW system IMHO.
serr is offline   Reply With Quote
Old 08-09-2016, 10:48 AM   #14
seymour22
Human being with feelings
 
seymour22's Avatar
 
Join Date: Nov 2013
Posts: 112
Default

Thanks! I was looking forward to see such an opinion. What is missing here on forum (piece of puzzle) I think non of you has utilized Mac Pro as strict server construction. I tak for granted big studios inest in that kind of machines due to their CPU cache, CPU and bus infrastrukture (indeed it must be more advanced than pc, iMacs). Also I as IT specialist can say I have never ever seen notebooks could be more efficient than servers: absurd, agree.

I guess the problem is how an APPLICATION has been written to utilized what... Pros might have 1 milion buffers and milon kgs CPUs that was better implemented, then all for nothing if Reaper and other DAWs cannot take advantage of it (same for VSTs, AU, etc.).

Another question: any Reaper's developers here? Have you ever been testing Reaper on Mac Pro? In Reaper there are milion properties, any specialist for servers like Mac Pro?

Kind regards
Tom.kw








Quote:
Originally Posted by serr View Post
Kind of absurd. The Mac Pros are the top spec machines. They have better cooling and are made to run at 100% 24/7.

When you want a tool that does that, that's what you buy.

Nothing against the iMac either. When you want a computer and display in the same box and the specs of the computer part meet your needs, the iMac can be the more efficient choice. Doesn't make it faster than the Mac Pro that you didn't need the extended capabilities of and thus didn't want to pay extra for.

That combo design choice happens to make the iMac the most expensive to repair or mod. Worst choice fit for a DAW system IMHO.
seymour22 is offline   Reply With Quote
Old 08-09-2016, 04:42 PM   #15
snooks
Banned
 
Join Date: Sep 2015
Posts: 1,650
Default

Actually server memory (ECC) is slower than ordinary memory. It's a great fit for servers though, where error correction is of higher value than a few percentage points of performance here or there. The increased cache per core in Xeons might compensate for this though.
snooks is offline   Reply With Quote
Old 08-10-2016, 05:49 AM   #16
avocadomix
Human being with feelings
 
Join Date: Mar 2016
Posts: 444
Default

iMacs run mobile CPUs, Mac Pro's run desktop CPUs. So performance-wise, this should make the Pro's about 2x as fast as the iMacs. And yes, CPU frequency is not all that matters, on-die cache is as important or more. As to ECC memory, it is a couple of percents slower but nothing to worry about.
Also the cooling system in modern iMacs is just terrible. A slim body, next to completely sealed, with only one fan. You can almost cook on it.
avocadomix is offline   Reply With Quote
Old 08-10-2016, 08:40 AM   #17
snooks
Banned
 
Join Date: Sep 2015
Posts: 1,650
Default

No, iMacs run desktop PCs... it's Mac Minis you are thinking about - they use laptop CPUs. Both iMacs and the new Mac Pros have sub optimal thermal cooling though.

Re ECC and extra caching, our multi-gigabyte memory footprint projects obviously can't live in the cache so for DAW purpose fast memory is more important that a slightly bigger cache that's being thrashed by a gazillion threads. For server purposes the extra cache makes great sense though.

Even if we want to add a couple of percentage points on for the extra caching, we are taking it away with the ECC. Which was my point... there's nothing inherently better about using server tech in DAWs, apart from being able to use multiple processors if you're planning on exceeding the number of cores available on a single CPU these days.
snooks is offline   Reply With Quote
Old 08-10-2016, 09:11 AM   #18
karbomusic
Human being with feelings
 
karbomusic's Avatar
 
Join Date: May 2009
Posts: 29,260
Default

Quote:
For server purposes the extra cache makes great sense though.
They are gonna be hit with thousands and thousands of threads - aka a DAW pales in comparison where threads are concerned. Not disagreeing, just mentioning.
__________________
Music is what feelings sound like.
karbomusic is offline   Reply With Quote
Old 08-10-2016, 02:11 PM   #19
avocadomix
Human being with feelings
 
Join Date: Mar 2016
Posts: 444
Default

Quote:
Originally Posted by snooks View Post
No, iMacs run desktop PCs... it's Mac Minis you are thinking about - they use laptop CPUs.
Checked the facts and this is correct.


Quote:
Re ECC and extra caching, our multi-gigabyte memory footprint projects obviously can't live in the cache so for DAW purpose fast memory is more important that a slightly bigger cache that's being thrashed by a gazillion threads. For server purposes the extra cache makes great sense though.
CPU on-die cache is not intended to be used for "normal" data storage. It is for chunks of data that were used or generated in the process of crunching. Example where it is useful for DAW purposes: suppose you have some plugin that applies a series of effects to the incoming stereo signal. Suppose that we are working in 64bit resolution, 512 samples buffer. So to process the whole buffer, we load 64*512*2=65536b=65.5kB from the RAM. So this is nowhere near gigabytes. Now as you add up more processing, more tracks and more code, that is where you begin to run out of cache. Then the CPU will need to pump data back and forth between the cache and the RAM which is a few orders of magnitude slower. This is where a larger cache is useful. And this is a typical DAW workload.

As to fast memory, the effect of the "speed" is pretty negligible and is offset by higher latencies. This is counterintuitive but this is a fact.

Last edited by avocadomix; 08-10-2016 at 02:22 PM.
avocadomix is offline   Reply With Quote
Old 08-10-2016, 02:28 PM   #20
seymour22
Human being with feelings
 
seymour22's Avatar
 
Join Date: Nov 2013
Posts: 112
Default

Dear all,

Yes, exactly, you can almost cook on it, however it has some value (almost I would buy it since it seems to be faster than others).

Actually I find some spectacular testings here:
https://www.youtube.com/watch?v=NJt3av99e8k

It would be a good point for all those waisting hours by thinking around which one is better. Looking on it I had no doubt Mac Pro is best for me. So after some days looking for I have choosen Mac Pro 4 cores since it has good results as single core (i double checked benchmarks for single core). Whi single core? Because you said VST/Real Time in most cases is multicore agnostic (to simplify).

As already have been written the problem is developers utilize what they find within Operating Systems ('as is' libraries, binaries). They call OS libraries, libraries call hardware. I am pretty sure there are no strict codes within DAWs to leverage big machines/servers' hardware infrastructures. It is funny even more (tears fun), because music studios world is going crazy with light speed ahead, faster and faster. In IT world you buy a server then install SAP or other stuff. While installing that stuff you MUST ADJUST your kernel (yes its true). For instance in AIX there are tones parameters to adjust your kernel due to SAP requirements. In some other unix you also must compile your OS kernel so that it can work in a good manner.

Here on Reaper Forum I can read - VST does not support multicore and so on... Hopeless... Of course I cannot blame on Reaper according to VST. However Reaper does not look better. You know, as Reaper fan I have read all those parameters visible when you hit 'ctrl+,'. Tones parameters but none of them to leverage strict/concrete machines. Some universal things like buffers, multithreading and so on.

So DEVELOPERS, any of you here? I think this is your future...

Kind regards
Tom.kw


Quote:
Originally Posted by avocadomix View Post
iMacs run mobile CPUs, Mac Pro's run desktop CPUs. So performance-wise, this should make the Pro's about 2x as fast as the iMacs. And yes, CPU frequency is not all that matters, on-die cache is as important or more. As to ECC memory, it is a couple of percents slower but nothing to worry about.
Also the cooling system in modern iMacs is just terrible. A slim body, next to completely sealed, with only one fan. You can almost cook on it.
seymour22 is offline   Reply With Quote
Old 08-11-2016, 01:03 AM   #21
snooks
Banned
 
Join Date: Sep 2015
Posts: 1,650
Default

@karbo: of course, you are correct. Maybe servers running scientific calculations where having 30MB and lots of horsepower would be an ideal cache leveraging scenario?

@avocadomix: I haven't seen low latency audio benchmarks demonstrating the advantage of slightly increased Xeon sized caches over i7. Theoretically there could be either an advantage, or very little/none. I think in the absence of lots of people reporting "holy crap!!" benchmarks that the effect is small, and perhaps offset by the (also small (but maybe bigger for low latency audio)) ECC hit.

We are talking about Xeons vs i7 equivalents in the context of low latency audio after all...

http://ark.intel.com/products/82930/...up-to-3_50-GHz

http://ark.intel.com/products/77912/...Cache-3_00-GHz

... where the difference in cache isn't too great.

Of course the best i7s aren't an option if you are choosing Mac.
snooks is offline   Reply With Quote
Old 10-05-2016, 04:21 PM   #22
acintya
Human being with feelings
 
Join Date: Sep 2010
Posts: 281
Default

i will maybe sell my 2x twelve core xeons. i think reaper is not ready to use all 24 core.12 is enough
acintya is offline   Reply With Quote
Old 10-05-2016, 10:57 PM   #23
Aeolian
Human being with feelings
 
Aeolian's Avatar
 
Join Date: Jun 2010
Location: Somewhere PRO
Posts: 1,049
Default

I've got a first gen i7 ... 4 actual cores, windows sees 8 cores, and they run at around 2.26 GHz

I've got another first gen i5 ... 2 actual cores, windows sees 4, and they run at 2.96 GHz

The i7 is waaaaaay more CPU efficient when it comes to multi track mixing, loading multiple plugs across tracks etc...

However, the i5 is significantly more CPU efficient if I run a single track, monitored live in real time, with lots of plugs, ie a cpu heavy amp sim or softsynth.
__________________
"REAPER... You're simply the best" - Tina Turner
Aeolian is offline   Reply With Quote
Old 10-06-2016, 12:51 AM   #24
G-Sun
Human being with feelings
 
G-Sun's Avatar
 
Join Date: May 2010
Location: Norway
Posts: 7,318
Default

Quote:
Originally Posted by karbomusic View Post
The biggest thing to be aware of is the Real time CPU thread which owns the handle to the audio driver, it can only live on a single thread which means a single core. You could have 5000 cores and the RT thread/core be maxed out causing pops/clicks.

And the obligatory YT video on the subject in general...

https://www.youtube.com/watch?v=GUsLLEkswzE
This is a very good explanation.
But for the buyer/builder, is it:
- Newer motherboard is better?
- Newer devices is better?
- Newer driver is better?
- Less devices is better?
and, cpu don't matter so much?
__________________
Reaper x64, win 11
Composer, text-writer, producer
Bandcamp
G-Sun is offline   Reply With Quote
Old 10-06-2016, 06:28 AM   #25
snooks
Banned
 
Join Date: Sep 2015
Posts: 1,650
Default

Quote:
Originally Posted by Aeolian View Post
I've got a first gen i7 ... 4 actual cores, windows sees 8 cores, and they run at around 2.26 GHz

I've got another first gen i5 ... 2 actual cores, windows sees 4, and they run at 2.96 GHz

The i7 is waaaaaay more CPU efficient when it comes to multi track mixing, loading multiple plugs across tracks etc...

However, the i5 is significantly more CPU efficient if I run a single track, monitored live in real time, with lots of plugs, ie a cpu heavy amp sim or softsynth.
Yes, that would be the case with the higher clock speed and same gen processor. However more cores makes a difference with the RT thread with "Allow live FX multiprocessing..." enabled when using more than one track...



Details of the gif:

i7 4720HQ, 4 cores + 4 HT cores.

Each track has ReaEQ, ReaComp and 4 x Guitar Rig 5 with 1993 Hot Solo preset

Without Live FX Multiprocessing (call it LFXM - I'm going to say it a few time) the RT thread is pretty much maxed out. It's proportionally reduced by enabling LFXM on more cores, with the sweet spot being the number of physical cores. You can see with 4 tracks that the RT CPU actually goes up here when allowing LFXM on more than 4 cores.

Not in gif, but with 8 tracks allowing LFXM on 8 cores reduces RT CPU very slightly compared to 4.
snooks is offline   Reply With Quote
Old 10-06-2016, 08:38 AM   #26
lolilol1975
Human being with feelings
 
Join Date: Dec 2015
Posts: 1,739
Default

Quote:
Originally Posted by acintya View Post
i will maybe sell my 2x twelve core xeons. i think reaper is not ready to use all 24 core.12 is enough
I think 24 cores would make sense in Reaper only if you have something like 100 or 200 plugins. Not exactly a common situation.
lolilol1975 is offline   Reply With Quote
Old 10-06-2016, 12:31 PM   #27
seymour22
Human being with feelings
 
seymour22's Avatar
 
Join Date: Nov 2013
Posts: 112
Default

Quote:
Originally Posted by snooks View Post
Y
Each track has ReaEQ, ReaComp and 4 x Guitar Rig 5 with 1993 Hot Solo preset

Without Live FX Multiprocessing (call it LFXM - I'm going to say it a few time) the RT thread is pretty much maxed out. It's proportionally reduced by enabling LFXM on more cores, with the sweet spot being the number of physical cores. You can see with 4 tracks that the RT CPU actually goes up here when allowing LFXM on more than 4 cores.

Not in gif, but with 8 tracks allowing LFXM on 8 cores reduces RT CPU very slightly compared to 4.
Hi all,
actually I decided to buy quad core Mac Pro (originally my intention was to buy 12 cores but i changed my mind). It was good decision. Actually I think there is no support on neither Reaper nor VST boards to utilize multicore servers. Please correct me if I am not making any sense.

Yes, I figured out there is "Allow live FX....." but frankly speaking I switched it on just for the reason AUDIO on background tracks sounds better when you listen to it while recording. Please look at my testing below and help me understand if should I use it or not.

OK, right now I am double checking some different combination of settings.
Also as you I created 4 tracks with same VSTs on each of them (PDC = 16394 for each tracks).

1st combination:
-------------------
Auto-detect the number of needed..... = 8 (Mac identified 8 automatically)
Allow live FX.... 4
Total CPU 11,6%
RT CPU 27,8%
RT longest block = 0,40ms/0.32ms

2nd combination:
--------------------
Auto-detect the number of needed..... = 0 (I set 0 manually)
Allow live FX.... inactive (means switched off)
Total CPU 8%
RT CPU 22.1%
RT longest block = 0,40ms/0.32ms (the same as above)

So, which one is better?

Kind regards
tom.kw
seymour22 is offline   Reply With Quote
Old 10-06-2016, 01:37 PM   #28
Aeolian
Human being with feelings
 
Aeolian's Avatar
 
Join Date: Jun 2010
Location: Somewhere PRO
Posts: 1,049
Default

Here, my rtcpu is way worse/higher if I have "allow live fx" turned on.

This happens on both my laptops.
__________________
"REAPER... You're simply the best" - Tina Turner
Aeolian is offline   Reply With Quote
Old 10-07-2016, 03:01 AM   #29
snooks
Banned
 
Join Date: Sep 2015
Posts: 1,650
Default

That's interesting, I'm on Win10 if that makes a difference. Also I checked at lower latencies and it's the same result - I can have completely distorted audio because the RT thread is going way over and enabling the option results in clean audio.

@seymour22: Applications don't know or care whether a core is on a separate processor or not so it shouldn't matter to Reaper. It seems as though you might think that the "Allow Live FX multiprocessing...." option is about being able to monitor audio too? It's just for distributing the load of rec-enabled tracks across cores.

Your results are different from mine too. Your RT thread looks like it's running over as well (0.40ms/0.32ms) and I don't know what effect have such high PDC (16000+ samples with tiny buffers like 16 @ 48kHz or 32 @ 96kHz buffer for that 0.32ms) would have on results.

The simple rule is that if you don't get dropouts doing what you're doing then everything is fine. If you do get dropouts then if changing something stops that then that's good.
snooks is offline   Reply With Quote
Old 10-07-2016, 03:06 AM   #30
G-Sun
Human being with feelings
 
G-Sun's Avatar
 
Join Date: May 2010
Location: Norway
Posts: 7,318
Default

I took a quick check on my
i5 4core
hdsp9632

and enabling 4 cores for RT seemed a tad better.
__________________
Reaper x64, win 11
Composer, text-writer, producer
Bandcamp
G-Sun is offline   Reply With Quote
Old 10-10-2016, 01:36 PM   #31
seymour22
Human being with feelings
 
seymour22's Avatar
 
Join Date: Nov 2013
Posts: 112
Default

Quote:
Originally Posted by snooks View Post
That's interesting /.../
O God! So sorry... My fault. I was checking all those parameters with no hitting 'record'. So right now it looks awesome!
All below made on 4 tracks simultaneously with ReaVerb on each:

1). Audio reading/processing threads = 0 (means switched off)
Allow live FX multiprocessing = off (0 above means this one if off)

Total CPU 3.7%
RT CPU 15.5 %
RT longest block = 4.04ms/0.73ms

2). Audio reading/processing threads = auto (means 8 on my Mac Pro quad core)
Allow live FX multiprocessing = off (I switched it off manually)

Total CPU 6.1%
RT CPU 14.1 %
RT longest block = 1.53ms/0.73ms

3). Audio reading/processing threads = auto (means 8 on my Mac Pro quad core)
Allow live FX multiprocessing = 4

Total CPU 7.5%
RT CPU 13.2 %
RT longest block = 0.74ms/0.73ms


So, the winner is number 3 /look at 'RT longest block'/. This is so good news.

Little bit worse is when you hover your mouse above this lettering within options: "Allow live FX" actually next to this lettering I mean above number of CPUs then you can see (at the bottom) the following info "The number should not be more than 2 or 4, even if you have more CPUs" - so.... little bit hopeless... I mean all the theories that 12 CPUs does not make any sense while working with Reaper are still true however it is still 'Audio reading/processing threads' which can be set to more than 2 or 4 (perhaps it has some value).

Thanks!
tom.kw
seymour22 is offline   Reply With Quote
Old 10-11-2016, 03:50 PM   #32
snooks
Banned
 
Join Date: Sep 2015
Posts: 1,650
Default

That's good news. Remember the 2-4 cores are just for live monitored FX, I don't know if there's a limit to the amount of cores Reaper can use for processing FX throughout a project on tracks that aren't being monitored live. That's the top figure, the one that automatically detects the cores on your computer.
snooks is offline   Reply With Quote
Old 10-12-2016, 05:30 AM   #33
Jack Winter
Human being with feelings
 
Jack Winter's Avatar
 
Join Date: Aug 2007
Location: Luxembourg/Spain
Posts: 1,922
Default

Quote:
Originally Posted by seymour22 View Post
So, the winner is number 3 /look at 'RT longest block'/. This is so good news.
Just be aware that RT longest block unfortunately resets at regular intervals, so you might have had a peak earlier but it won't be shown as the max value has reset.
__________________
Reaper for Linux Documentation (WIP). Software: Archlinux/KDE, Fabfilter FX, Komplete 8, Nebula, Schwa/Stillwell, T-racks Max/Amplitube/SVX, etc. Gear: i7-2600k/4700HQ/16GB, RME Multiface/Babyface, Behringer X32, Genelec 8040, etc. :)
Jack Winter is offline   Reply With Quote
Old 10-17-2016, 12:51 PM   #34
seymour22
Human being with feelings
 
seymour22's Avatar
 
Join Date: Nov 2013
Posts: 112
Default

Quote:
Originally Posted by G-Sun View Post
This is a very good explanation.
But for the buyer/builder, is it:
- Newer motherboard is better?
- Newer devices is better?
- Newer driver is better?
- Less devices is better?
and, cpu don't matter so much?
Dear G-Sun,
I think CPU Architecture would be there as a focal point. However, even though I said 'CPU Architecture" I did not buy the most fresh iMac i7 but Mac Pro quad core. What means there are some other advantages you consider when decided to change your gears (cooling, cache, and more).

So, in general (RT improvement) I still say 'CPU Architecture' (more GHz, better CPU bus, cache). Another thing is even though I was looking for carefully I could not say big machines (like Mac Pro) are better utilized by Reaper. Using another words - Reaper does not seem to be server oriented. It has been built rather for mostly used hardware (like PC, iMac, MacBooks). For example - there are some option you can take advantage and one of them is: 'Allow live FX multiprocessing on' but when you hover your mouse over this (means how many CPUs you want to set) you can see a context help below: 'no more 2 or 4'. Also for instance you decide to buy a big machine then you realize your state of the art CPU CACHE is not utilized by Reaper (VST similarly).

Frankly speaking, developers and in general a companies have certain strategies. So, it is just how it is

Take care!
tom.kw
seymour22 is offline   Reply With Quote
Old 01-17-2018, 09:18 PM   #35
Cableaddict
Human being with feelings
 
Join Date: Apr 2008
Posts: 1,910
Default

Quote:
Originally Posted by seymour22 View Post

So, the winner is number 3 /look at 'RT longest block'/. This is so good news.

Little bit worse is when you hover your mouse above this lettering within options: "Allow live FX" actually next to this lettering I mean above number of CPUs then you can see (at the bottom) the following info "The number should not be more than 2 or 4, even if you have more CPUs" - so.... little bit hopeless... I mean all the theories that 12 CPUs does not make any sense while working with Reaper are still true however it is still 'Audio reading/processing threads' which can be set to more than 2 or 4 (perhaps it has some value).
I must bump this thread, to correct a SERIOUS error:

Yes, the little prompt at the bottom of Reaper's buffer settings window DOES say this, but it's wrong, wrong WRONG.

(Did I mention that it's wrong?)


As you may know, this week I've been doing massive research and experimentation on getting the smallest HW buffer / lowest latency for my "live performance" Reaper rigs. Granted, this is not a typical scenario for most users, but within this context, the above prompt is horribly incorrect.

I never noticed that little pop-up prompt until I read this thread, so for years I've been setting "anticipative" to on, and with a setting of 2X my cores. (16, for my current 8 core cpu.)

Well, I read this thread today, and was all excited to change my setting form "16" to "4," but as soon as I did, my session started crackling like a bag of Orville Reddenbacher's.

It's back to "16" for me, and I can still record about 20 tracks of my band live, all while live-monitoring about 50 tracks.

YMMV, but without question, there are times when limiting that setting to only 4 cores is a big mistake.
---------------------


That's my story, and I'm sticking with it.
Cableaddict is offline   Reply With Quote
Old 01-18-2018, 04:15 AM   #36
Dr Bob
Human being with feelings
 
Dr Bob's Avatar
 
Join Date: Apr 2007
Location: Yorkshire, UK
Posts: 2,063
Default

Just to add to the RT cpu use part of this thread ...

As I and others have pointed out in various threads ...

Moving ALL FX off the Reaper MASTER track makes a big improvement on the RT cpu. Simply making your own master buss, and routing everything to that which would normally have defaulted to the reaper master track and then let that buss track go to the Reaper master and then on to your audio output, works wonders. Put your "master chain" FX on your new master buss. I see a reduction from say 4% RT cpu down to 0.3% on my big fast machine, and even better on my old 7 yr old quadcore.

I know it's a PITA to re-route everything, but once your master fx are on a new buss, they can take advantage of the multiprocessing, which AFIK does not happen on the master track, and also do not compete with the RT thread on the same cpu.

If this does wonders for you - let us know.

dB
Dr Bob is online now   Reply With Quote
Old 01-18-2018, 04:22 AM   #37
Jack Winter
Human being with feelings
 
Jack Winter's Avatar
 
Join Date: Aug 2007
Location: Luxembourg/Spain
Posts: 1,922
Default

IMO it would be real nice if the master fx could also optionally be anticipative, as long as there are no recarmed tracks...
__________________
Reaper for Linux Documentation (WIP). Software: Archlinux/KDE, Fabfilter FX, Komplete 8, Nebula, Schwa/Stillwell, T-racks Max/Amplitube/SVX, etc. Gear: i7-2600k/4700HQ/16GB, RME Multiface/Babyface, Behringer X32, Genelec 8040, etc. :)
Jack Winter is offline   Reply With Quote
Old 01-18-2018, 09:01 AM   #38
serr
Human being with feelings
 
Join Date: Sep 2010
Posts: 12,557
Default

I also disagree with the conventional wisdom of setting a single core for audio processing in Reaper. (I've always seen it mentioned to use 1 core, not 2 or 4 FWIW.)

Reaper absolutely wants two things: Control over how it determines multi core use and full access to your CPU. Turn hyperthreading off in your EFI firmware. In Reaper preferences, set the number of cores for audio processing to the number of physical CPU cores you have.
serr is offline   Reply With Quote
Old 01-18-2018, 09:10 AM   #39
karbomusic
Human being with feelings
 
karbomusic's Avatar
 
Join Date: May 2009
Posts: 29,260
Default

Quote:
Originally Posted by serr View Post
I also disagree with the conventional wisdom of setting a single core for audio processing in Reaper. (I've always seen it mentioned to use 1 core, not 2 or 4 FWIW.)
Sounds like some are conflating this with the fact that the thread that talks the "audio driver" can only be one thread no matter how many cores/procs you have. There is no setting for that because it is a physical limitation.
__________________
Music is what feelings sound like.
karbomusic is offline   Reply With Quote
Old 01-18-2018, 10:33 AM   #40
Dr Bob
Human being with feelings
 
Dr Bob's Avatar
 
Join Date: Apr 2007
Location: Yorkshire, UK
Posts: 2,063
Default

Of course, but on which cpu that audio thread sits is what can cause disruptive audio behaviour if that cpu is also expected to do a lot more extra processing. From what I have seen, pushing the RT value gets you ultimately into crackle territory, so anything which can diminish the RT use has to be a good thing.

I also have not tweaked my new Windows 10 system at all (yet!), and everything is ticking away very nicely.

dB
Dr Bob is online now   Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -7. The time now is 05:16 AM.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.