Old 10-02-2018, 10:05 AM   #1
WorkInProgress23
Human being with feelings
 
Join Date: Aug 2018
Posts: 6
Default Reaper Crashing During Tracking Only

Hello, all. Apologies if this is the wrong place to ask, or if it's been asked before. I've been unable to find a solution based on my research.

I have been using Reaper for about 2 years with the same hardware setup. Within the last month I've experienced a new issue while tracking. Seemingly at random, while the musician is tracking, the playback of the previous tracks will simply mute for a moment or two. The visual of the currently recording track will blank out, then reappear as normal once playback resumes. When listening back, there is no skipping and all tracks sound perfectly fine, but as you can imagine this is not ideal for a musician to try to play perfectly in time while the rest of the audio pauses and starts at random. There is no issue with playback at all when not recording.

The only other detail I've noticed is that the part of the transport bar that shows "playing" along with the time of the song will flash red when the skipping begins, then return to normal when the audio resumes.

I'm using a Dell XPS 15 laptop on Windows 7 with a Focusrite Scarlett 18i8, and as stated I haven't had this issue while tracking in the last 2 years with this setup. I've tried moving a session to another Dell laptop on Windows 10 and noticed no issue, so I'm positive the issue is with my laptop. Reaper version is v5.95/x64 currently, and I tend to update often.

I've deleted or moved almost every file that's not necessary for my current projects, so space isn't an issue. My antivirus (Iolo) is up to date and reports no issues. I've taken it to a repair shop and was told the hard drive checked out as well as the motherboard. They found no software issues either, except a few outdated drives, but of course updating those didn't solve the issue either.

I thought maybe it was the specific project that was corrupted, or maybe the amount of tracks and fx was overwhelming my laptop. However I've now noticed this issue with a brand new project while tracking drums (5 mics). The drummer was only using 2 playback tracks (1 at a time at that) and the skipping still resumed on the single track he was playing to. So a corrupted project, or too heavy of a workload is out of the question too.

I apologize for the long read, but I wanted to include as much detail as possible. Thanks in advance if anyone has the time to look over and perhaps share if you've heard of a similar issue with Reaper.

Last edited by WorkInProgress23; 10-02-2018 at 10:32 AM. Reason: Including reaper version
WorkInProgress23 is offline   Reply With Quote
Old 10-02-2018, 12:14 PM   #2
foxAsteria
Human being with feelings
 
foxAsteria's Avatar
 
Join Date: Dec 2009
Location: Axis Mundi
Posts: 4,902
Default

A few things you can try:

Track with few or no fx. Remove/disable fx on the master chain especially. Cpu intensive or fx with a large pdc buffer can cause such dropouts (Check the performance meter window for details). A trick you can do to quickly reduce cpu in a heavy project when you need to do some more recording is send all the existing tracks to a subproject. This gives you a rendered audio file for the whole project to work with, and you can simply double click it to re-enter the project for further editing. It's like track-freeze for your whole project.

Raise the buffer/latency size in your audio device control panel (accessed in preferences/audio/device/asio config button)

Disable anti-virus while tracking. Real-time antivirus can interfere with recording, as it tries to access, scan and even block the newly created files.
__________________
TwilightMysterySchool
foxAsteria is online now   Reply With Quote
Old 10-02-2018, 07:59 PM   #3
WorkInProgress23
Human being with feelings
 
Join Date: Aug 2018
Posts: 6
Default

Quote:
Originally Posted by foxAsteria View Post
A few things you can try:

Track with few or no fx. Remove/disable fx on the master chain especially. Cpu intensive or fx with a large pdc buffer can cause such dropouts (Check the performance meter window for details). A trick you can do to quickly reduce cpu in a heavy project when you need to do some more recording is send all the existing tracks to a subproject. This gives you a rendered audio file for the whole project to work with, and you can simply double click it to re-enter the project for further editing. It's like track-freeze for your whole project.

Raise the buffer/latency size in your audio device control panel (accessed in preferences/audio/device/asio config button)

Disable anti-virus while tracking. Real-time antivirus can interfere with recording, as it tries to access, scan and even block the newly created files.

Hello, Asteria. Thank you for the suggestions.

During my most recent tracking session, I had only 7 tracks (recording 5 drum tracks at a time with 1 track playing back). Should I attempt to recreate the crash with even fewer tracks? I only ask because I previously have been able to record in projects that contained a few dozen tracks with no issue.

I also keep real-time disabled for my anti-virus usually, and disable entirely during tracking.

I'm not sure I fully understand your sub-projects suggestion, but it sounds very helpful! I'll look into that more. I'll also try raising the buffer/latency and attempt tracking again
WorkInProgress23 is offline   Reply With Quote
Old 10-03-2018, 01:04 PM   #4
foxAsteria
Human being with feelings
 
foxAsteria's Avatar
 
Join Date: Dec 2009
Location: Axis Mundi
Posts: 4,902
Default

Subprojects are a feature that allow you to have projects within other projects, but they are represented by rendered audio in the parent project (thus needing no processing). Search the actions list for "subproject" and you will see actions to move tracks to one. This is only necessary if your project is using a lot of cpu (check the performance meter window).

This is a useful (and free) utility that works like an upgraded task manager: https://processhacker.sourceforge.io/ If you run it during a session and click the "system information" button in the top of the window, it will show you detailed, real-time graphs of your computer activity. You can use it to troubleshoot if/which part of the system is getting overtaxed during these dropouts.

Buffer/latency size of your audio device is the first thing to try though. It is very common to start with a low one early in the project and slowly raise it as it grows. If it becomes too high for tracking, use freezing or subprojects to lower the resource usage, so the latency can again be lowered.
__________________
TwilightMysterySchool
foxAsteria is online now   Reply With Quote
Old 10-03-2018, 02:50 PM   #5
alanofoz
Human being with feelings
 
alanofoz's Avatar
 
Join Date: Sep 2009
Location: Oz - Blue Mountains NSW, formerly Geelong
Posts: 706
Default

Longshot: do you have any plugins operating in trial mode?
__________________
It's "its" except when it's "it is".

bunyipmusic.com
alanofoz is offline   Reply With Quote
Old 10-03-2018, 02:59 PM   #6
karbomusic
Human being with feelings
 
karbomusic's Avatar
 
Join Date: May 2009
Posts: 22,838
Default

Quote:
The only other detail I've noticed is that the part of the transport bar that shows "playing" along with the time of the song will flash red when the skipping begins, then return to normal when the audio resumes.
1. Open Reaper's Performance meter (View > Performance meter).

2. Right-click on the left of the window and choose "Show real time (RT) CPU on graph"

3. See if that real time thread is pegging @ 100% when the issue occurs - if it is - you are CPU bound on the audio thread which lives on a single CPU core - small chance of relief based on how your tracks/folders/master FX are setup.

4. Check the disk read/write times and report back what they are during the issue - especially if it's not #3 as that will indicate being disk bound aka the disk not keeping up even though the processor is.
karbomusic is online now   Reply With Quote
Old 10-03-2018, 03:46 PM   #7
serr
Human being with feelings
 
Join Date: Sep 2010
Posts: 7,493
Default

That's the starting point there. ^^^

Take a look at Activity Monitor (Task Manager in Windows I think) as well. It should agree with the Reaper performance meter.

So the audio drops out, the peak view picture stops being drawn, but... the incoming audio keeps recording.
Aside: Shout out for Reaper's priorities! Saved the live recording. (A moot point here perhaps but there it is.)

My blind guess would be hard drive speed issues.

If you're tracking by using the built-in mixer in your interface to monitor the live input - not doing live low latency tracking through plugins that is - make sure you don't inadvertently have your latency (block size) set low. That would be like driving on the freeway in first gear.

If you ARE tracking live through VSTi instrument plugins or amp sims or whathaveyou, well then low latency is a hard requirement. So you need to take up the slack somewhere else.

Got a SSD in that machine?
If not, treat yourself to that upgrade. 5x to 10x performance increase.
serr is offline   Reply With Quote
Old 10-04-2018, 02:00 AM   #8
clepsydrae
Human being with feelings
 
clepsydrae's Avatar
 
Join Date: Nov 2011
Posts: 2,147
Default

Random side shot-in-the-dark: I have an 18i20 and use it with Windows (8.1) -- occasionally the drivers are wonky and it gets into a weird sample rate/latency setting through no action or configuration of my own. E.g. 192k and 128 samples, or something crazy like that. Opening the control panel and setting it back fixes things fine. If it's doing that it might cause unnecessary CPU usage when you're recording, so maybe just double check that it hasn't gone out of whack.

(Edit: for me this never happens while recording, though, just e.g. on reboots; I'm not suggesting your dropouts are from this change happening while recording.)
clepsydrae is offline   Reply With Quote
Old 10-06-2018, 03:24 PM   #9
WorkInProgress23
Human being with feelings
 
Join Date: Aug 2018
Posts: 6
Default

Quote:
Originally Posted by foxAsteria View Post
Subprojects are a feature that allow you to have projects within other projects, but they are represented by rendered audio in the parent project (thus needing no processing). Search the actions list for "subproject" and you will see actions to move tracks to one. This is only necessary if your project is using a lot of cpu (check the performance meter window).

This is a useful (and free) utility that works like an upgraded task manager: https://processhacker.sourceforge.io/ If you run it during a session and click the "system information" button in the top of the window, it will show you detailed, real-time graphs of your computer activity. You can use it to troubleshoot if/which part of the system is getting overtaxed during these dropouts.

Buffer/latency size of your audio device is the first thing to try though. It is very common to start with a low one early in the project and slowly raise it as it grows. If it becomes too high for tracking, use freezing or subprojects to lower the resource usage, so the latency can again be lowered.

Apologies for the late reply, I didn't have much time during this past work week to apply any of the suggestions.

Today I was (ironically) unable to recreate the glitch, despite tracking in 2 different projects that had the issue previously. So I'm not too sure how much help my stats will be, but I did download process hacker.

Between process hacker, performance monitor, and Reaper's RT CPU graph, it looks like I'm averaging around 10-15% usage when tracking. Disk read/write times seemed to average around 600 to 250. Again, the issue did not occur today so I'm not sure if that info helps.

Two other notes:
I'm not using any plugins in trial mode
Everything seems to check out in the Scarlett control panel

I'm going to attempt to recreate the bug tomorrow once again to gather accurate performance stats, as I find it hard to believe the issue has simply solved itself over night after 2 months (though I won't mind!).

I am also a bit lost when it comes to what buffer/sample/latency should be, and how much they should be raised for tracking instruments? Currently my ASIO config shows request sample rate at 44100 and request block size at 256.

Many thanks for all the help so far.
WorkInProgress23 is offline   Reply With Quote
Old 10-06-2018, 03:37 PM   #10
WorkInProgress23
Human being with feelings
 
Join Date: Aug 2018
Posts: 6
Default

Quote:
Originally Posted by serr View Post
That's the starting point there. ^^^

Take a look at Activity Monitor (Task Manager in Windows I think) as well. It should agree with the Reaper performance meter.

So the audio drops out, the peak view picture stops being drawn, but... the incoming audio keeps recording.
Aside: Shout out for Reaper's priorities! Saved the live recording. (A moot point here perhaps but there it is.)

My blind guess would be hard drive speed issues.

If you're tracking by using the built-in mixer in your interface to monitor the live input - not doing live low latency tracking through plugins that is - make sure you don't inadvertently have your latency (block size) set low. That would be like driving on the freeway in first gear.

If you ARE tracking live through VSTi instrument plugins or amp sims or whathaveyou, well then low latency is a hard requirement. So you need to take up the slack somewhere else.

Got a SSD in that machine?
If not, treat yourself to that upgrade. 5x to 10x performance increase.
I agree, props to Reaper for prioritizing the live recording!

I am not tracking through any amp simps or instrument plugins, but my latency may be the issue. My block size is currently set at 256 and I'm unsure what it should be set at. I've looked the subject up a bit but I found a lot of suggestions not to adjust it at all.
WorkInProgress23 is offline   Reply With Quote
Old 10-07-2018, 10:38 AM   #11
foxAsteria
Human being with feelings
 
foxAsteria's Avatar
 
Join Date: Dec 2009
Location: Axis Mundi
Posts: 4,902
Default

Quote:
Originally Posted by WorkInProgress23 View Post
I am also a bit lost when it comes to what buffer/sample/latency should be, and how much they should be raised for tracking instruments? Currently my ASIO config shows request sample rate at 44100 and request block size at 256.
It sounds like you are setting the block size in Reaper's audio device preferences. Right below that setting is the "ASIO configuration" button. Click it to access your devices control panel and that's where you should make those settings.

256 samples is usually pretty good for tracking, but lower is better if you don't get noise or dropouts. 512 is manageable but I really start to notice the latency and I only go higher than that in big, cpu heavy projects. The control panel setting might be measured in milliseconds instead of samples on your device.

Either way, that's where you set the buffer size (unless it's not possible; then continue using Reaper's settings). Sample rate is fine at 44.1k or 48k, but the benefits of going higher than that are a matter of debate and you are unlikely to need or notice them under normal circumstances. The main goal of these settings is to achieve the lowest latency your computer can handle with the highest fidelity. It's common to change the buffer size regularly, depending on what you're doing.
__________________
TwilightMysterySchool
foxAsteria is online now   Reply With Quote
Old 10-07-2018, 10:53 AM   #12
serr
Human being with feelings
 
Join Date: Sep 2010
Posts: 7,493
Default

Quote:
Originally Posted by WorkInProgress23 View Post
I agree, props to Reaper for prioritizing the live recording!

I am not tracking through any amp simps or instrument plugins, but my latency may be the issue. My block size is currently set at 256 and I'm unsure what it should be set at. I've looked the subject up a bit but I found a lot of suggestions not to adjust it at all.
Suggestions to not adjust it at all?! That's just wrong! It's the starting point in using a DAW.

The block size is literally the latency control. It's how much time (in samples) you give the DAW to process audio. If it takes more CPU cycles to process than you give it, you get dropouts.

Doing live sound with a computer (in other words, running with a block size at a sample rate that gives the computer 11ms or less to process the audio) is not SOP and hasn't even been possible until more recent times. So... audio interfaces include a built-in mixing board (like their own internal DAW app) to handle monitoring live inputs for overdubbing.

If you have a fast computer, you can set that block size low and actually pass sound in real time for live sound or performance use.

Doing live sound with a fast computer?
Set the block size low enough for < 11ms round trip latency.

Just mixing and NOT doing anything live?
Set the block size high (eg 1024 samples) to save CPU cycles for the mix processing.

Some tips:
48k is usually the sweet spot for a sample rate for running a low block size for live use. Lowest latency possible with least CPU use. Going to 96k (even though a single sample is now a shorter time interval) crosses the line into more CPU use for the same latency.

If you get an interface that gives you under 10ms at a block size of 128 samples running at 48k, you'll have lots of headroom to load up on plugins. If you need to workaround a higher baseline latency interface with a lower block size just to get it under 10ms, you've used up your headroom already and you'll have a hard time.

And again, if you're not doing live sound, set your block size to 512 or 1024 samples to open up headroom on your system. (Careful with values above 1024 samples. Not all interfaces support it and it can cross the line and use up more processing power again.)

That help?


PS. Reaper gives you the ability to control interfaces with 3rd party apps or control panel apps. Untick the box for sample rate or block size to disable control from Reaper to allow this. Note that if you have unticked those boxes but not used a 3rd party control panel app to set them, they will be set to "who knows?"
serr is offline   Reply With Quote
Old 10-07-2018, 11:17 AM   #13
foxAsteria
Human being with feelings
 
foxAsteria's Avatar
 
Join Date: Dec 2009
Location: Axis Mundi
Posts: 4,902
Default

Quote:
Originally Posted by serr View Post
And again, if you're not doing live sound, set your block size to 512 or 1024 samples to open up headroom on your system.
can you plz explain how block size has anything to do with headroom? that's not something i've ever heard of.
__________________
TwilightMysterySchool
foxAsteria is online now   Reply With Quote
Old 10-07-2018, 12:47 PM   #14
clepsydrae
Human being with feelings
 
clepsydrae's Avatar
 
Join Date: Nov 2011
Posts: 2,147
Default

Quote:
Originally Posted by foxAsteria View Post
can you plz explain how block size has anything to do with headroom? that's not something i've ever heard of.
serr is talking about CPU headroom, not audio headroom.
clepsydrae is offline   Reply With Quote
Old 10-07-2018, 12:51 PM   #15
serr
Human being with feelings
 
Join Date: Sep 2010
Posts: 7,493
Default

Quote:
Originally Posted by foxAsteria View Post
can you plz explain how block size has anything to do with headroom? that's not something i've ever heard of.
The less time you give the CPU to process everything, the more demanding it can be. A larger block size gives your system more time to process everything. Which leads to being able to open more plugins as well as some heavier resource plugins then you would have been able to at a lower block size.

Some plugins have a larger minimum processing time themselves. Any plugin that has a higher internal processing latency than your block size is off limits in that live scenario. A larger block size lats you use some of those plugins.
serr is offline   Reply With Quote
Old 10-07-2018, 03:30 PM   #16
foxAsteria
Human being with feelings
 
foxAsteria's Avatar
 
Join Date: Dec 2009
Location: Axis Mundi
Posts: 4,902
Default

Quote:
Originally Posted by clepsydrae View Post
serr is talking about CPU headroom, not audio headroom.
i see. somehow i've never heard the word used that way.
__________________
TwilightMysterySchool
foxAsteria is online now   Reply With Quote
Old 10-09-2018, 12:30 PM   #17
WorkInProgress23
Human being with feelings
 
Join Date: Aug 2018
Posts: 6
Default

Quote:
Originally Posted by foxAsteria View Post
It sounds like you are setting the block size in Reaper's audio device preferences. Right below that setting is the "ASIO configuration" button. Click it to access your devices control panel and that's where you should make those settings.

256 samples is usually pretty good for tracking, but lower is better if you don't get noise or dropouts. 512 is manageable but I really start to notice the latency and I only go higher than that in big, cpu heavy projects. The control panel setting might be measured in milliseconds instead of samples on your device.

Either way, that's where you set the buffer size (unless it's not possible; then continue using Reaper's settings). Sample rate is fine at 44.1k or 48k, but the benefits of going higher than that are a matter of debate and you are unlikely to need or notice them under normal circumstances. The main goal of these settings is to achieve the lowest latency your computer can handle with the highest fidelity. It's common to change the buffer size regularly, depending on what you're doing.
Many thanks again for you, and everyone else's detailed replies. For the record, I was able to get through tracking another 2 whole songs without the glitch (5 drum tracks together, 2 separate guitar tracks, and 3 separate vocal tracks). This was a project very similar to the ones I've experienced crashing with before, and I have not yet made any buffer/latency adjustments. For all intents and purposes the problem has "vanished". That said, I am still looking into all of the other suggestions provided as I know they'll still improve my setup's performance tremendously!

You were right Asteria, I have been checking in Reaper's audio device preferences as opposed to the Scarlett control panel. I also see what Serr means by unchecking the sample rate/block size boxes to disable control from Reaper.

After re-reading your helpful comments, and reviewing several videos/articles on the buffer topic, it almost fully clicks for me. So my current understanding is that adjusting buffer size, block size, or latency all means the same thing. It sounds like best practice would be for me to lower my block size to 128 or 64 while tracking, so long as I do not begin experiencing glitches/hiccups again.

However when mixing, or when the project load grows so much (or if I have similar crashes again...) that's when I would want to increase my block size to 512 or maybe 1024 in order to decrease the burden on my CPU.

Can you confirm my last 2 paragraphs add up? Sorry if I'm being overly analytical here, but I want to fully understand the "why" behind these possible adjustments now that I'm realizing how crucial these fundamentals are Thanks for your patience!

Sample rate is indeed a heavily debated subject that I will look more into next, so I'll leave that at 44.1k for now as suggested.
WorkInProgress23 is offline   Reply With Quote
Old 10-09-2018, 12:52 PM   #18
foxAsteria
Human being with feelings
 
foxAsteria's Avatar
 
Join Date: Dec 2009
Location: Axis Mundi
Posts: 4,902
Default

Yes, I think you basically got it. Buffer/block size is too small if you get dropouts and it's too big if the latency (delay between playing and instrument and hearing the sound) interferes with your timing. In other words, a bigger buffer allows your computer to do more work without running out of resources, but also takes more time and thus increases audible latency. It's a balance, but priories change whether you are recording or mixing.
__________________
TwilightMysterySchool

Last edited by foxAsteria; 10-09-2018 at 01:10 PM.
foxAsteria is online now   Reply With Quote
Old 10-09-2018, 12:58 PM   #19
WorkInProgress23
Human being with feelings
 
Join Date: Aug 2018
Posts: 6
Default

Quote:
Originally Posted by serr View Post
Suggestions to not adjust it at all?! That's just wrong! It's the starting point in using a DAW.

The block size is literally the latency control. It's how much time (in samples) you give the DAW to process audio. If it takes more CPU cycles to process than you give it, you get dropouts.

Doing live sound with a computer (in other words, running with a block size at a sample rate that gives the computer 11ms or less to process the audio) is not SOP and hasn't even been possible until more recent times. So... audio interfaces include a built-in mixing board (like their own internal DAW app) to handle monitoring live inputs for overdubbing.

If you have a fast computer, you can set that block size low and actually pass sound in real time for live sound or performance use.

Doing live sound with a fast computer?
Set the block size low enough for < 11ms round trip latency.

Just mixing and NOT doing anything live?
Set the block size high (eg 1024 samples) to save CPU cycles for the mix processing.

Some tips:
48k is usually the sweet spot for a sample rate for running a low block size for live use. Lowest latency possible with least CPU use. Going to 96k (even though a single sample is now a shorter time interval) crosses the line into more CPU use for the same latency.

If you get an interface that gives you under 10ms at a block size of 128 samples running at 48k, you'll have lots of headroom to load up on plugins. If you need to workaround a higher baseline latency interface with a lower block size just to get it under 10ms, you've used up your headroom already and you'll have a hard time.

And again, if you're not doing live sound, set your block size to 512 or 1024 samples to open up headroom on your system. (Careful with values above 1024 samples. Not all interfaces support it and it can cross the line and use up more processing power again.)

That help?


PS. Reaper gives you the ability to control interfaces with 3rd party apps or control panel apps. Untick the box for sample rate or block size to disable control from Reaper to allow this. Note that if you have unticked those boxes but not used a 3rd party control panel app to set them, they will be set to "who knows?"
Hey Serr, your info and tips have been very helpful as well. I do have a silly question just to make sure I follow. When you mention "live sound" you're referring to tracking an instrument in general right? Not specifically recording a whole "live" performance such as at a concert?

I'm not entirely sure how fast my laptop is (especially with an hdd lol), but is it safe to use the latency in milliseconds in the top right corner of Reaper to determine if my block size and sample rate are are giving my cpu enough time to process the audio? I've honestly never paid attention to that number simply because I've never heard any noticeable playback delay/latency while tracking.

One more question. You and a few others mentioned taking a look at what my CPU performance/utilization is at when Reaper would crash. As noted in my last few posts, I'm unable to get the crash to occur again. I am however curious what "healthy" numbers would look like for CPU utilization. Both while tracking using minimal plugins, as well as when mixing with a full workload.

I figure if I have an idea of what a good range is, I'll be make a little more sense of my trial and error results with adjusting buffer size.

Also is "Show real time (RT) CPU on graph" in Reaper's performance meter the spot to look for this info? After digging through other threads it sounds like my normal Windows activity monitor may not be the most accurate.

Quote:
Originally Posted by foxAsteria View Post
Yes, I think you got it.
Thanks again!!
WorkInProgress23 is offline   Reply With Quote
Old 10-09-2018, 01:02 PM   #20
serr
Human being with feelings
 
Join Date: Sep 2010
Posts: 7,493
Default

The only time latency would matter is if you are running sound through the computer. Playing a VSTi instrument or playing a live mic'd input through some plugin fx. Anything where you hear real life + the output from the computer at the same time and thus would hear a lag in the computer. This is the scenario where you have to set the block size low to achieve that below perception latency.

If you monitor live overdubs with your audio interface and just record and mix, you should leave the block size set to the max high for your system. Usually 512 or 1024 samples. (Higher than that usually gets counterproductive again.)

Block size is called buffer or input buffer in other DAWs, yes. The disk buffer (for playback from disk only) is also a buffer. Careful not to confuse the controls.

I thought headroom in a system was just a general engineering term that was also used in audio. No?
serr is offline   Reply With Quote
Old 10-10-2018, 01:26 PM   #21
azslow3
Human being with feelings
 
Join Date: Nov 2017
Location: Heidelberg, Germany
Posts: 486
Default

Several comments:

* audio/other glitches.
- many things happened in background, especially when OS "think" the computer is not used (f.e. recording 30min without touching mouse/keyboard), and especially when it is "online". Before important session, it can be worse to check the task manager for planned for next hours tasks (in the task manager) and bring networking down
- thin notebooks (I also have Dell XPS) are not well suited for full power processing (maxed CPU). They simply get hot. Check there is nothing closing ventilation halls (f.e. soft material on table) and no external devices add to that (like heater in the near). Also there is programs like PowerPlanSwitcher with allows quickly change power profile. When CPU use is low in important sessions, it can make sense to define special profile with lower max frequency (f.e. 2GHz).

* buffers.
One of the biggest REAPER feature is anticipative processing.
In short, it allows to keep audio buffer at the lowest settings even during mixing/mastering heavy projects. So unlike in some other DAWs, there is in general no reason to modify the buffer depending on use mode.
Technically, all not live signals (so everything not armed, including backing tracks during recording) are processed like with high buffer all the time when that feature is on.
Note that default "Render-ahead" is 200ms and that introduce inconvenience in plug-in GUIs (they show signal 200ms ahead of played time). But ~50ms almost eliminate that problem, keeping all advantages.
azslow3 is offline   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 09:22 PM.


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