Why is My New Computers Audio Crapping Out?

[SEA]

I just built a new Dual Xeon 12 Core, 32gig computer and I'm running Windows 7 64. My interface is a Focusrite Liquid Saffire 56 and I'm running it at 512 latency.

In each track I have about 5 plugs I'm adding plugs to each track (VCC, J37, CLA-76, Pro-Q, etc.) and like 10 tracks with all these plugs in each. Now while I was moving the J37 into another track all of a sudden "Crunch, Pop, crackle" like the sound you get when you CPU is maxed out. However, my CPU is at 5% and my 32gig of memory is like a 3%

It's not like I don't have the power. So what could be the problem?


Any tips would be great!

SEA

[serr]

Well... look at that. Sounds like the exact issue that's cropping up for me!

Take a look at my posts about this:
http://forum.cockos.com/showpost.php...90&postcount=3
http://forum.cockos.com/showpost.php...39&postcount=7
http://forum.cockos.com/showpost.php...0&postcount=12

[SEA]

Originally Posted by serr

Well... look at that. Sounds like the exact issue that's cropping up for me!

Take a look at my posts about this:
http://forum.cockos.com/showpost.php...90&postcount=3
http://forum.cockos.com/showpost.php...39&postcount=7
http://forum.cockos.com/showpost.php...0&postcount=12

Thanks! I'll check the links out!

[serr]

Just to be clear, I don't have a solution!


You'll see from my posts and titles that I first suspected operator error (and did in fact discover one). But then the same issue came back (OE wasn't the root or main cause). Then I suspected misbehaving plugins... You'll see...

Really looks like a bug in Reaper at this point.

[SEA]

Originally Posted by serr

Well... look at that. Sounds like the exact issue that's cropping up for me!

Take a look at my posts about this:
http://forum.cockos.com/showpost.php...90&postcount=3
http://forum.cockos.com/showpost.php...39&postcount=7
http://forum.cockos.com/showpost.php...0&postcount=12

I read where your issue was when 1 of your cores were maxed out. As you can see in my pic, all my cores are barely being used and I have the crunchy, poppy, like my CPU is crapping out issue still.

[SEA]

Originally Posted by serr

Really looks like a bug in Reaper at this point.

I have Studio One V2. I might just have to try that and see if I can duplicate this problem.

Do you have another daw software you can try?

SEA

[serr]

Originally Posted by SEA

I read where your issue was when 1 of your cores were maxed out. As you can see in my pic, all my cores are barely being used and I have the crunchy, poppy, like my CPU is crapping out issue still.

Nope.
Again sorry for the confusion with my thinking jumping from one symptom to the next in the thread titles.

In case I wasn't clear enough, I had cpu history open watching all cores. No cores maxed out. The "1 core's worth" and "100%" comments are intended to explain the activity monitor's way of reporting cpu use. You can watch the cores individually and the total cpu use (for this machine) would be reported as 1600%.

This sounds exactly like what you are seeing. The computer running almost at idle but Reaper acting like you have a red-lined machine.

Could Reaper perhaps just not be optimized for multi-core machines?

It looks like (at the moment anyway) something like that might be going on.

[SEA]

What about an earlier reaper build? Maybe it's a bug in the latest versions.

How can we let Justin know about this?

[serr]

Originally Posted by SEA

What about an earlier reaper build? Maybe it's a bug in the latest versions.

How can we let Justin know about this?

I'm going to go through older versions later and report back.


I was still in 4.6.something when I first had issues a few weeks ago. I was assuming it was an issue with UAD plugins at that time.

[SEA]

Originally Posted by serr

I'm going to go through older versions later and report back.


I was still in 4.6.something when I first had issues a few weeks ago. I was assuming it was an issue with UAD plugins at that time.

Thanks serr! Keep me posted!

I'm posting a thread on the main board now. See if others are having this same issue.

[SEA]

I just built a new Dual Xeon 12 Core, 32gig computer and I'm running Windows 7 X64 and Reaper's latest build X64.

In each track I have about 5 plugs I'm adding plugs to each track (VCC, J37, CLA-76, Pro-Q, etc.) and like 10 tracks with all these plugs in each. Now while I was loading more plugs on a track all of a sudden I hear "Crunch, Pop, Crackle" like the sound you get when you CPU is maxed out. However, my CPU is at 5% and my 32gig of memory is like a 3%

My interface is LS 56. I'm ASIO buffer is at 512.

It's not like I don't have the power. So what could be the problem?

Are others having this issue?

SEA

[Xenakios]

Are you loading the 64 bit builds of the plugins into 64 bit Reaper? If bit bridging is involved (like when you load 32 bit plugins into 64 bit Reaper), the overheads involved may be such that even large amounts of CPU and RAM won't help enough. (The problem with bit bridging is having to wait for the communication between different processes to happen, not necessarily how much CPU cycles are available.)

[SEA]

Originally Posted by Xenakios

Are you loading the 64 bit builds of the plugins into 64 bit Reaper? If bit bridging is involved (like when you load 32 bit plugins into 64 bit Reaper), the overheads involved may be such that even large amounts of CPU and RAM won't help enough. (The problem with bit bridging is having to wait for the communication between different processes to happen, not necessarily how much CPU cycles are available.)

Yep! This is happening when loading multiple instances of 64bit plugs in 64bit Reaper.

[serr]

Originally Posted by Xenakios

Are you loading the 64 bit builds of the plugins into 64 bit Reaper? If bit bridging is involved (like when you load 32 bit plugins into 64 bit Reaper), the overheads involved may be such that even large amounts of CPU and RAM won't help enough. (The problem with bit bridging is having to wait for the communication between different processes to happen, not necessarily how much CPU cycles are available.)

Happening for me in both all 32 bit and all 64 bit installs.

If your theory as to what's happening still applies, would this be something that there is no telltale for?

[serr]

Just trying a few things quick before my session here...

I have this Reaper project at a point where adding one more heavy enough plugin goes from perfect snappy GUI and everything to broken clicking and popping POS in every version I tried.

Oh, and I can try a few different ones with the same result including ReaVerberate. More evidence that this is not a misbehaving plugin issue at it's core.

Tried a few versions jumping back as far as 3.75.

Same problem across the board. However, in v3 I see spikes here and there in different cores in activity monitor! Clear obvious spikes. No spikes to see in the meters when running v4 even though it's hitting the wall at the same place. Things going past the 50% mark in some cores but no spikes to see. But Reaper acting like it's maxed out.


So... Did we really just hit the wall of what Reaper can do? And mad CPU power is kind of a moot point because after a point you just won't be able to use any more anyway?

Or a bug? Or Reaper not quite into multi-core operation yet?

Or maybe operator error? I'd love for someone to show me I missed something that fixes everything.

[SEA]

Originally Posted by serr

So... Did we really just hit the wall of what Reaper can do? And mad CPU power is kind of a moot point because after a point you just won't be able to use any more anyway?

It better not cause if it is I'm moving back to Cubase (or Studio One) where a friend of mine can load up TONS more plugs on a lesser built machine than MINE!!!

I call mine "The Beast!" It's 12 cores, 32 gigs (can hold 64 gigs) 24 threads, and built to never EVER need another daw until technology goes into "Star Trek Vill" or something

[serr]

Here's 3.75 vs 4.7 with activity monitor cpu meter

I always see 4 cores with activity and 4 with idling and then the 2 groups of 4 swap back and forth. You see they just swapped in the 4.7 shot.

[karbomusic]

What does Reapers real-time CPU display show in Reaper's performance monitor? You may have to right click to see it. You could have 150,000 CPU cores but only one handles the real time processing for the audio driver and one thread can only run on a single core IIRC.

[serr]

Originally Posted by SEA

It better not cause if it is I'm moving back to Cubase (or Studio One) where a friend of mine can load up TONS more plugs on a lesser built machine than MINE!!!

I call mine "The Beast!" It's 12 cores, 32 gigs (can hold 64 gigs) 24 threads, and built to never EVER need another daw until technology goes into "Star Trek Vill" or something

I hear ya!

Even with this limitation (if it turns out that way which I'm in no way ready to accept), this is still better than Protools HD. Studio One was the closest contender when I did a DAW shootout 5 years ago but still wasn't as stable as Reaper. It flat out didn't cut it for running live sound. Anyway...

The project I have up is 107 tracks, 114 plugins, subgroup and fx bus routing, automation. 24 bit 88.2k sample rate.
Using the Apogee and currently have the disc buffer at 2048 samples.


I was just messing around with the buffer settings again.
When you are well within the headroom of the system, different thread priority & behavior settings seem to make zero difference.

So I left them at default.

I just topped these both out to time critical and very aggressive. This let the test session with the extra plugin that was breaking it run now!

I also notice Reaper is using 8 cores now instead of only 4. Alright.

I have number of audio threads set to 1 (instead of 16 by auto-detect)
I remember this being recommended a long time ago. If I change this to anything greater than 1, CPU use literally doubles and the session really grinds to a stop. Seems pretty black and white there.

Curious about that default though and I'm pretty sure I've seen a few posts with someone claiming the opposite on that.

[serr]

Originally Posted by karbomusic

What does Reapers real-time CPU display show in Reaper's performance monitor? You may have to right click to see it. You could have 150,000 CPU cores but only one handles the real time processing for the audio driver and one thread can only run on a single core IIRC.

That's around 85%. Pushing the system over the edge again pushes it up to 95% (yes, I can still break it if I load even more heavy plugins)

Maybe that's the meter I was missing?

What exactly does 'real time processing' refer to? If it's the live audio to/from the interface, that would only be 2 channels in one direction at present.


Still surprised to be hitting any wall with Reaper. It's been this perfectly stable unstoppable force for a good long while now! I still have it in my head that the live sound + recording thing is a notable benchmark. Maybe only 36 tracks but it's with a 128 sample buffer. Running for hours with no breaks and not so much as a chirp or click. (You've seen all my smart talk on the forum.)

This is just boring old studio work. Stupid amount of tracks and fx and all but the computer has all the time in the world to think about it. Or so I thought...

[karbomusic]

Originally Posted by serr

That's around 85%. Pushing the system over the edge again pushes it up to 95% (yes, I can still break it if I load even more heavy plugins)

Maybe that's the meter I was missing?

What exactly does 'real time processing' refer to? If it's the live audio to/from the interface, that would only be 2 channels in one direction at present.

Short story, a thread can typically only do work on a single core and the audio endpoint (driver) is a single thread. Point being a person can see pops and clicks with only a small "total" CPU usage because one of the cores (the one with the real time critical audio thread on it) is maxed out. RT CPU time displayed in Reaper should be the cpu usage of that thread/core.

Additionally, even that one may not need to be maxed out visually. IOW it has always been my experience that pops/clicks are going to occur before hitting 100% because you have to leave some room for interrupts and DPCs.

Another thing I can throw at you is that the "behavior" setting in the thread preferences in Reaper in my experience is exactly the opposite of what it appears. Right now mine is on "Automatic experimental" which worked best for me but in previous testing I found that 0 - Relaxed actually reduced pops/clicks and 10 - Very aggressive made them much worse. It can be tricky because this is tweaking how threads are prioritized and scheduled and what seems like the obvious choice many times isn't. Anticipative FX processing was also a big contributor (or helper) with this depending, depending on what, I don't remember.

[SEA]

Originally Posted by karbomusic

Another thing I can throw at you is that the "behavior" setting in the thread preferences in Reaper in my experience is exactly the opposite of what it appears. Right now mine is on "Automatic experimental" which worked best for me but in previous testing I found that 0 - Relaxed actually reduced pops/clicks and 10 - Very aggressive made them much worse. It can be tricky because this is tweaking how threads are prioritized and scheduled and what seems like the obvious choice many times isn't. Anticipative FX processing was also a big contributor (or helper) with this depending, depending on what, I don't remember.

I'll give this a try and see if it helps!

However, why does Cubase 6.5 on my friends machine (which isn't as powerful as mine) can handle WAY more plugs than Reaper?

Is it a design flaw or a limitation?

I PM Justin about this so hopefully we'll hear back something soon.

[SEA]

Originally Posted by Justin

Try setting prefs/buffering/thread behavior to "automatic (experimental)".. we'll probably make this the default in future versions..

The Current version is 4.7 and the default was set to 4. I set it to"Automatic (experimental) and also tried 0 - relaxed.

Still CPU crunching like Crazy!

Check out my CPU pic!

[Ollie]

I merged your threads/posts on the topic here. It's doesn't help helping you if the information is spread all over the place.

To summarize,

- you are having that problem permanently after or only while moving that plug-in?

- does that happen with all plug-ins or just some? (Try a completely different set of plug-ins if possible)

- does that also happen with REAPER stock-plug-ins only?

- Your last screenshot shows one (logical?) core nearly maxing out. What (model?) CPU(s) are you using? Is that really 2 Xeon 12-cores or one 12-core CPU with Hyperthreading? What's the mainboard make/model, do you use the latest BIOS and was that board successfully used in a DAW before?

Edit:

- Did you make sure that EIST/C1E/TurboBoost and all other power (saving) related options were turned off in the BIOS? If you built that computer yourself and didn't turn them off, that's probably all still on. This can cause varying issues when the load changes and the clock(s) change their pace. You can use e.g. CPU-Z to check whether or not your clocks and voltages remain stable. This also includes checking if the power scheme is set appropriately in Windows.

Originally Posted by serr

Well... look at that. Sounds like the exact issue that's cropping up for me!

You may have the same symptom but that doesn't mean you're having the same issue, in particular since you're using the other platform. "Snap crackle and pop" is the #1 issue everywhere when it comes to running a DAW, this is due to the extremely varied causes this symptom has. In almost any problem thread, the obligatory "I have the same issue" post is more often than not only adding to the confusion, in particular in "snap, crackle and pop"-threads.

[Aeolian]

Originally Posted by karbomusic

Short story, a thread can typically only do work on a single core and the audio endpoint (driver) is a single thread. Point being a person can see pops and clicks with only a small "total" CPU usage because one of the cores (the one with the real time critical audio thread on it) is maxed out. RT CPU time displayed in Reaper should be the cpu usage of that thread/core.

Additionally, even that one may not need to be maxed out visually. IOW it has always been my experience that pops/clicks are going to occur before hitting 100% because you have to leave some room for interrupts and DPCs.

Another thing I can throw at you is that the "behavior" setting in the thread preferences in Reaper in my experience is exactly the opposite of what it appears. Right now mine is on "Automatic experimental" which worked best for me but in previous testing I found that 0 - Relaxed actually reduced pops/clicks and 10 - Very aggressive made them much worse. It can be tricky because this is tweaking how threads are prioritized and scheduled and what seems like the obvious choice many times isn't. Anticipative FX processing was also a big contributor (or helper) with this depending, depending on what, I don't remember.

Karbo nailed it to the wall

Quite a few users here have no idea about RT CPU, which i didnt either until about 9 months ago, when this same problem bit me hard.

In Reaper, i now never look at my cpu meter without checking rt cpu as well.

I find that rt cpu is typically very low here, but rises expotentially if i arm tracks with heavy plugins on them, which makes perfect sense because armed "live" tracks are much harder to multi-thread than unarmed tracks.

In Short: armed tracks use lots of RT CPU (which can only use a single thread)
Unarmed tracks should use much less RT CPU.

[SEA]

Thanks Ollie for your response!

Originally Posted by Ollie

Are you are having that problem permanently after or only while moving that plug-in?

Permanently. It happens with not just the J37, but I used other plugs and load it up and still happens. I used u-he Satin and loaded it in replacement of he J37 in about 5 or 6 tracks and getting the same problem.

does that happen with all plug-ins or just some? (Try a completely different set of plug-ins if possible)

It happens with other plugs as well. Although I noticed it took like twice as many instances of some plugs to trip Reaper like FabFilter Pro Q vs. Satin or J37. Seems like with the Pro Q that Reaper could handle more instances of it.

I also through in there like 5 instances more of the CLA 76.

does that also happen with REAPER stock-plug-ins only?

I just loaded up 30 tracks with each track having the following Reaper plugs:

ReaGate
ReaComp
ReaCom
ReaCom
Reaverbate
Reaverbate

So far all is good! No audible crunching!

Your last screenshot shows one (logical?) core nearly maxing out. What (model?) CPU(s) are you using? Is that really 2 Xeon 12-cores or one 12-core CPU with Hyperthreading? What's the mainboard make/model, do you use the latest BIOS and was that board successfully used in a DAW before?

Asus Z9PA-D8 (MB)

Dual Xeon E5-2620v2 (6 cores each) with Hyperthreading.

BIOS is up to date.

Here's the specs of my processors.

http://ark.intel.com/products/75789/...Cache-2_10-GHz

Did you make sure that EIST/C1E/TurboBoost and all other power (saving) related options were turned off in the BIOS? If you built that computer yourself and didn't turn them off, that's probably all still on. This can cause varying issues when the load changes and the clock(s) change their pace. You can use e.g. CPU-Z to check whether or not your clocks and voltages remain stable. This also includes checking if the power scheme is set appropriately in Windows.

I will check on this.

[Cosmic]

I have a i7 rig with 16 gigs of ram and I can run over a thousand vsts at 128


at 48 I can use around 100..although I've never even done an eighth of that on my productions.

Your computer should DEFO be able to do the biz..ya gotta get phorensic

[serr]

Originally Posted by karbomusic

Short story, a thread can typically only do work on a single core and the audio endpoint (driver) is a single thread. Point being a person can see pops and clicks with only a small "total" CPU usage because one of the cores (the one with the real time critical audio thread on it) is maxed out. RT CPU time displayed in Reaper should be the cpu usage of that thread/core.

Additionally, even that one may not need to be maxed out visually. IOW it has always been my experience that pops/clicks are going to occur before hitting 100% because you have to leave some room for interrupts and DPCs.

That's all reasonable. No argument there.

Originally Posted by karbomusic

Another thing I can throw at you is that the "behavior" setting in the thread preferences in Reaper in my experience is exactly the opposite of what it appears. Right now mine is on "Automatic experimental" which worked best for me but in previous testing I found that 0 - Relaxed actually reduced pops/clicks and 10 - Very aggressive made them much worse. It can be tricky because this is tweaking how threads are prioritized and scheduled and what seems like the obvious choice many times isn't. Anticipative FX processing was also a big contributor (or helper) with this depending, depending on what, I don't remember.

Played around with different combinations some more.

The 10 - Very aggressive setting is still the best performance here.
Lower settings will only really use 4 cores at a time. You see 8 with the higher setting.

Anticipative FX processing is drastically worse! Runs for 3 or 4 seconds and then the transport just lights up flashing red and Reaper grinds to a stop.


I will say that the little bit extra you get from the '10 - Very aggressive' setting isn't a lot. But it let me pull 1 extra larger plugin up.



Alright, well, so I found the limit for Reaper here for post production. I might have to freeze a track here and there once I go over 100 tracks and 100 plugins running at high sample rates. And it took me 5 years to notice it.

Unless I want to get a computer that runs faster than 3.33GHz I suppose.
I remember choosing between a faster 8-core vs. the new but not quite as fast running 12-core when I put this machine together and I went with the 8. Once again pleased with that decision!

Originally Posted by Ollie

You may have the same symptom but that doesn't mean you're having the same issue, in particular since you're using the other platform. "Snap crackle and pop" is the #1 issue everywhere when it comes to running a DAW, this is due to the extremely varied causes this symptom has. In almost any problem thread, the obligatory "I have the same issue" post is more often than not only adding to the confusion, in particular in "snap, crackle and pop"-threads.

I did say "sounds like".

I was probably a little excited at the thought of the possibility to find a bug or user error so I jumped in.

I think the big reveal here was the RT CPU meter. Now that I see a telltale for maxing out an aspect of the system all is well. This all seems to reinforce that I've made all the correct setting for everything too. Although I'm still curious about the disagreement on a couple of them.

I mean, it would be great if you could get more plugins running of course! But I'm good with this. Better than what Protools HD was doing for me.

[SEA]

Originally Posted by Ollie

You can use e.g. CPU-Z to check whether or not your clocks and voltages remain stable. This also includes checking if the power scheme is set appropriately in Windows.

I ran the CPU Z while I had DPC Latency Checker running. When CPU-Z wasn't running the DPC-Z looked fine! All in the green like 1/4 inch at the bottom. But as soon as I ran CPU-Z, then BAM! Got all this red!

I attached a pic.

Is CPU-Z causing the spikes? Soon as I exit it everything is fine again.

Here's the link to the software

http://www.cpuid.com/softwares/cpu-z.html

It also loaded spy ware etc. Now I gotta get rid of that!

[karbomusic]

The 10 - Very aggressive setting is still the best performance here.
Lower settings will only really use 4 cores at a time. You see 8 with the higher setting.

That's what I'm trying to say but I would caution fixating on number of cores used etc. It's not always as simple as the visually obvious (not saying that's the case here, bigger picture) but I'm also saying that what works will NOT be the same for every user, that is precisely why they are settings that can be changed. If it never needed to be changed why have a setting lol?

Anticipative FX processing is drastically worse! Runs for 3 or 4 seconds and then the transport just lights up flashing red and Reaper grinds to a stop.

See above, the setting exists because no two systems or how they are used or the VSTs used are identical. I'd almost bet you could have a different human using different VSTs and workflows have the exact opposite experience on the exact same machine so you need to choose the setting that works best for you assuming the defaults don't work.

[Mink99]

Try latencymon, Even a powerful machine might fail on hidden flaws, eg USB card driver, graphics driver or stuff like that .

http://www.resplendence.com/latencymon

[SEA]

Originally Posted by Mink99

Try latencymon, Even a powerful machine might fail on hidden flaws, eg USB card driver, graphics driver or stuff like that .

http://www.resplendence.com/latencymon

Ran LatencyMon

Here's what the pic looks like when running Reaper

Here's what the report said

__________________________________________________ __________________________________________________ _____
CONCLUSION
__________________________________________________ __________________________________________________ _____
Your system appears to be suitable for handling real-time audio and other tasks without dropouts.
LatencyMon has been analyzing your system for 0:08:41 (h:mm:ss) on all processors.


__________________________________________________ __________________________________________________ _____
SYSTEM INFORMATION
__________________________________________________ __________________________________________________ _____
Computer name: JAMIE-PC
OS version: Windows 7 Service Pack 1, 6.1, build: 7601 (x64)
Hardware: Z9PA-D8 Series, ASUSTeK COMPUTER INC.
CPU: GenuineIntel Intel(R) Xeon(R) CPU E5-2620 v2 @ 2.10GHz
Logical processors: 24
Processor groups: 1
RAM: 32718 MB total


__________________________________________________ __________________________________________________ _____
CPU SPEED
__________________________________________________ __________________________________________________ _____
Reported CPU speed: 2100.0 MHz
Measured CPU speed: 1263.0 MHz (approx.)

Note: reported execution times may be calculated based on a fixed reported CPU speed. Disable variable speed settings like Intel Speed Step and AMD Cool N Quiet in the BIOS setup for more accurate results.


__________________________________________________ __________________________________________________ _____
MEASURED INTERRUPT TO USER PROCESS LATENCIES
__________________________________________________ __________________________________________________ _____
The interrupt to process latency reflects the measured interval that a usermode process needed to respond to a hardware request from the moment the interrupt service routine started execution. This includes the scheduling and execution of a DPC routine, the signaling of an event and the waking up of a usermode thread from an idle wait state in response to that event.

Highest measured interrupt to process latency (µs): 603.170424
Average measured interrupt to process latency (µs): 7.930619

Highest measured interrupt to DPC latency (µs): 453.474935
Average measured interrupt to DPC latency (µs): 1.865679


__________________________________________________ __________________________________________________ _____

[karbomusic]

Reported CPU speed: 2100.0 MHz
Measured CPU speed: 1263.0 MHz (approx.)

?????

Turn off speed stepping/cie (which Ollie already mentioned) but that woulda shoulda shown up in CPUID as well assuming you ran it without the system under heavy load. - I see why, that CPU-Z screen shot is way too small for me to see.

[SEA]

Originally Posted by karbomusic

Reported CPU speed: 2100.0 MHz
Measured CPU speed: 1263.0 MHz (approx.)

?????

Turn off speed stepping/cie (which Ollie already mentioned) but that woulda shoulda shown up in CPUID as well assuming you ran it without the system under heavy load. - I see why, that CPU-Z screen shot is way too small for me to see.

Working on getting into the BIOS. F1 & F2 didn't do it, so once I figure it out that's next!

[SEA]

So after getting into the BIOS I did what Ollie said by disabling EIST/C1E/TurboBoost and all other power (saving) options in the BIOS (just 1 other thing) and it seems to run better. Instead of 3 or 4 additional J37 plugs I can now load like 6 or 7 before hearing noticeable crackling.

So it is better but still have more to go!

[Mink99]

Hi sea,

Next test, switch your graphics driver from nvidia to standard windows generic driver. Test again with latencymon.bthe values from the screenshot are far too high ... The dpc latency should be below 70 .

[Ollie]

Another thing you could try is restricting Preferences->Audio->Buffering->"Audio reading/processing threads" to the number of physical cores in your system (12). This is effectively turning off Hyperthreading for REAPER.

(But your screenshot looks like REAPER is already set to use only the 12 physical cores or it's not using HT for other reasons, in which case I'd turn it off at any rate.

On some systems with e.g. Intel i7 CPUs, REAPER can gain quite some performance using HT, but this is most likely depending on a lot more factors than the CPU type.)

[SEA]

Originally Posted by Ollie

(But your screenshot looks like REAPER is already set to use only the 12 physical cores or it's not using HT for other reasons, in which case I'd turn it off at any rate.

So I should try turning off HT in my BIOS to see if
I gain performance correct?

[SEA]

Originally Posted by Mink99

Hi sea,

Next test, switch your graphics driver from nvidia to standard windows generic driver. Test again with latencymon. The values from the screenshot are far too high ... The dpc latency should be below 70 .

I just swapped out to the standard windows generic driver and it didn't help.

[serr]

Played around some more last night with different combinations of settings. Tried to be thorough is trying all combinations...

Best for my system:
Most critical:
Preferences/Audio/Buffering -> "Audio reading/processing threads" set to 1
Preferences/Audio/Buffering -> "Anticipate FX processing" unchecked

Less critical:
Preferences/Audio/Buffering -> "Thread priority" set to 'Time critical'
Preferences/Audio/Buffering -> "Behavior" set to '15 - Very aggressive'
Hyperthreading off (command line in Terminal for OSX)


The 'less critical' settings let me get 2 Waves linear phase eq's up where I was maxed out before with default settings. Changing the 'most critical' settings to anything else makes the cpu use double and really shuts things down.

Looked at the link for 'latencymon' and only see Windows versions. I could run it but would the results be meaningful in OSX?