Reaper audio dropping with high latency plugins on folders

[EpicSounds]

Confirmed fix? Everyone is happy with the change in 6.80 ???

[ferropop]

I haven't found a situation yet (after trying many previously-forbidden routings) where I'm getting even a hiccup.

I do wonder what settings everyone is using -- it's SO easy to tweak a single buffering setting and have a drastically-different experience. It's unsettling knowing that (can attest) you can have tweaked a setting 8 years ago and have been suffering for it the entire time (the Time-Critical vs Relaxed example). Happy to share mine.

[the19thbear]

Seems like its working MUCH better now! A project with lots of high latency plugins on the master bus and on various busses, would be almost unplayable because of crackles. Now it runs perfectly.

[jhkillam]

Originally Posted by ferropop

the Time-Critical vs Relaxed example

What did you find about this? I think I have mine on the default and don’t really understand what it does.

[the19thbear]

Originally Posted by ferropop

I haven't found a situation yet (after trying many previously-forbidden routings) where I'm getting even a hiccup.

I do wonder what settings everyone is using -- it's SO easy to tweak a single buffering setting and have a drastically-different experience. It's unsettling knowing that (can attest) you can have tweaked a setting 8 years ago and have been suffering for it the entire time (the Time-Critical vs Relaxed example). Happy to share mine.

Please do share

[gelbfinger]

Originally Posted by EpicSounds

Confirmed fix? Everyone is happy with the change in 6.80 ???

Projects that i could barely play before cause of contstant crackles work flawlessly now. They have folder structures, sends and also a few plugins running in rosetta. NO PROBLEM after the update !
More then happy ! THANKS to everyone who did theire part in fixing this.

[gelbfinger]

Originally Posted by ferropop

I haven't found a situation yet (after trying many previously-forbidden routings) where I'm getting even a hiccup.

I do wonder what settings everyone is using -- it's SO easy to tweak a single buffering setting and have a drastically-different experience. It's unsettling knowing that (can attest) you can have tweaked a setting 8 years ago and have been suffering for it the entire time (the Time-Critical vs Relaxed example). Happy to share mine.

Would be glad to see your settings !

[ELBAJISTA33]

Greetings, in version 6.79 I had no difficulty at least for what I need, but with this new version I had this problem: There is an expected delay of half a second in playback and stopping, and also a delay in muting / remuting the sound and solo / unsolo (I wish it were instantaneous, of course). If I copy and paste from someone I described earlier, but now it happens to me. I use the brauerize and when I activate the FX of folders the latency starts. I use a ryzen 5000 and a VOLT 476P. I have the Bufer size in 2048, please who can help me to solve this difficulty I appreciate it, thank you very much

[ferropop]

Tweaking these all the time, but have found a nice balance between stability and responsiveness with the above. Also running at 64 samples block-size.

[dyross]

Originally Posted by ELBAJISTA33

Greetings, in version 6.79 I had no difficulty at least for what I need, but with this new version I had this problem: There is an expected delay of half a second in playback and stopping, and also a delay in muting / remuting the sound and solo / unsolo (I wish it were instantaneous, of course). If I copy and paste from someone I described earlier, but now it happens to me. I use the brauerize and when I activate the FX of folders the latency starts. I use a ryzen 5000 and a VOLT 4769P. I have the Bufer size in 2048, please who can help me to solve this difficulty I appreciate it, thank you very much

I was running into this too, and I too use 2048 often. Justin suggested I look at the longest "chain" of PDC from single track to master and noted that it adds up quickly.

Remember, that if you have *any* PDC on a track, even 1 sample, it rounds (the track) up to your block size (2048), so it can add up quickly.

With the threading improvements of this build, I can run my same project at, like, 256 pretty well.

[ELBAJISTA33]

Originally Posted by dyross

I was running into this too, and I too use 2048 often. Justin suggested I look at the longest "chain" of PDC from single track to master and noted that it adds up quickly.

Remember, that if you have *any* PDC on a track, even 1 sample, it rounds (the track) up to your block size (2048), so it can add up quickly.

With the threading improvements of this build, I can run my same project at, like, 256 pretty well.

thank you very much, I heard that the latency issues are solved by going up to 250 unfortunately uses more CPU. This can be considered a problem, as it cannot be mixed to 1024 or 2048 without generating latency. I repeat, in version 6.79 I mixed to 2048 without any difficulty and using some Acoustic Audio ZL plugins. Hopefully this can be repaired.

[hexSPA]

Originally Posted by ferropop

Tweaking these all the time, but have found a nice balance between stability and responsiveness with the above. Also running at 64 samples block-size.

I see you're using Thread Priority Behavior 0-Relaxed which is supposed to reduce stability at lower latencies (which I take to include buffers) and your buffer is 64 so that's about as low as it gets. Typically, I'm using HW monitoring so my buffer is 1024 samples.

As someone who doesn't tweak these settings often and hasn't researched them, can you share what kind of changes I might expect as a result of copying your settings? Thanks.

[Gianlorenzo Mungiovino]

Guys, can we all confirm that the isssue related to high PDC plugins on folder tracks has been fixed with the latest 6.80 update?
For me the improvement has been HUGE.

Still cannot believe this annoying issue is now gone away..

Thank you Cockos <3

[Gianlorenzo Mungiovino]

Originally Posted by EpicSounds

Confirmed fix? Everyone is happy with the change in 6.80 ???

I cannot still believe... everything is working properly now

[hexSPA]

Originally Posted by Gianlorenzo Mungiovino

Guys, can we all confirm that the isssue related to high PDC plugins on folder tracks has been fixed with the latest 6.80 update?
For me the improvement has been HUGE.

Still cannot believe this annoying issue is now gone away..

Thank you Cockos <3

Yes, I agree it's a significant though underplayed update. Other DAWs would do a whole hype cycle on it. People here are saying it's fixed.

[the19thbear]

yeah, its amazing! Finally I can work again. It is like getting my CPU back/getting a new computer.

[ScuzzyEye]

Originally Posted by hexSPA

Yes, I agree it's a significant though underplayed update. Other DAWs would do a whole hype cycle on it. People here are saying it's fixed.

That's what's funny, coming from another DAW, Reaper (pre-fix) was still more efficient. I could load things up much farther. The problem was when Reaper finally gave up, it behaved much worse. That's what even more impressive about this fix. It didn't just fix the misbehaving state, it actually seems to have made the normal operating mode more efficient still.

[barbaroja]

Nice to read all this. However:

I am still getting a incredibly high CPU usage when a track is record armed and changes drastically when in a folder structure. The deeper it is, the worse. Even 30% higher just with one track selected just because of it being inside a folder. Haven't found a setting that improves on this either in the buffering section of options.

Here is a typical buss/folder structure with the % that it uses if monitoring input in each position: (It does the same regardless of it being MIDI or audio input)

Premaster/Group Mix (6%)
-Buss Vocals(15%)
--Main Vocals (30%)
---L
---R
---Center (50-60%)
--BG Vocals
---L
---R
---Center
-Other tracks/Busses
-...

Basically, looks like RT CPU doubles each time it goes inside a folder.

Tried all possible combinations of disabling folder/parent send, routing directly to master, to same folder but out of folder structure. Whenever audio goes into a folder CPU usage skyrockets.

Even more weird, even at 30%RT Usage I get all sorts of clicks, pops, noises and other gremlins, just for the fact of monitoring live input inside a folder. I use a reasonalby modern computer, well optimized for DAW use. 30%RT should be still useable. But not.

The change when not monitoring is truly absurd, goes down to around 4%RT from 60%RT, even when inside a folder.

Finding this thread gives me hope, there might be something that can be done. Let me know if this might need its own thread or makes sense to post here.

Thanks.

[Gianlorenzo Mungiovino]

Originally Posted by barbaroja

Nice to read all this. However:

I am still getting a incredibly high CPU usage when a track is record armed and changes drastically when in a folder structure. The deeper it is, the worse. Even 30% higher just with one track selected just because of it being inside a folder. Haven't found a setting that improves on this either in the buffering section of options.

Here is a typical buss/folder structure with the % that it uses if monitoring input in each position: (It does the same regardless of it being MIDI or audio input)

Premaster/Group Mix (6%)
-Buss Vocals(15%)
--Main Vocals (30%)
---L
---R
---Center (50-60%)
--BG Vocals
---L
---R
---Center
-Other tracks/Busses
-...

Basically, looks like RT CPU doubles each time it goes inside a folder.

Tried all possible combinations of disabling folder/parent send, routing directly to master, to same folder but out of folder structure. Whenever audio goes into a folder CPU usage skyrockets.

Even more weird, even at 30%RT Usage I get all sorts of clicks, pops, noises and other gremlins, just for the fact of monitoring live input inside a folder. I use a reasonalby modern computer, well optimized for DAW use. 30%RT should be still useable. But not.

The change when not monitoring is truly absurd, goes down to around 4%RT from 60%RT, even when inside a folder.

Finding this thread gives me hope, there might be something that can be done. Let me know if this might need its own thread or makes sense to post here.

Thanks.

There are too much variables on the scenario you're showing;
What are the specs of your PC?
Windows settings? (huge separate chapter)
Interface, driver and buffer size used?
Are there fx add to the master track?

Let's start with disabling live FX multithread or at least reducing the amount of cores involved.

Anyway I'm reading that specific project you were working on got over 200 fx loaded, it may not be a light load for you system especially if, as I can image, your CPU is a 6 cores with multithreading.

[barbaroja]

Originally Posted by Gianlorenzo Mungiovino

There are too much variables on the scenario you're showing;
What are the specs of your PC?
Windows settings? (huge separate chapter)
Interface, driver and buffer size used?
Are there fx add to the master track?

Let's start with disabling live FX multithread or at least reducing the amount of cores involved.

Anyway I'm reading that specific project you were working on got over 200 fx loaded, it may not be a light load for you system especially if, as I can image, your CPU is a 6 cores with multithreading.

I get what you're saying but it is just too particular that such a spike in CPU usage occurs only when record armed. And doubles when going inside folders. Doubt it's related to computer performance.
If the computer was the bottleneck, then it would crap out way sooner, I think. Performance meter CPU RT does not even reach 10% if not armed!

Seems like Reaper has to assign the whole route from subfolders to master out to one core? Dunno, never had this issue while using other daws, it's just too strange.

[sockmonkey72]

Originally Posted by barbaroja

I get what you're saying but it is just too particular that such a spike in CPU usage occurs only when record armed. And doubles when going inside folders. Doubt it's related to computer performance.
If the computer was the bottleneck, then it would crap out way sooner, I think. Performance meter CPU RT does not even reach 10% if not armed!

Seems like Reaper has to assign the whole route from subfolders to master out to one core? Dunno, never had this issue while using other daws, it's just too strange.

https://forums.cockos.com/showthread.php?p=2224592 might give you some insight.

[barbaroja]

Originally Posted by sockmonkey72

https://forums.cockos.com/showthread.php?p=2224592 might give you some insight.

Good resource. I did enable anticipative FX for live input, to no avail.

[EpicSounds]

Originally Posted by barbaroja

Good resource. I did enable anticipative FX for live input, to no avail.

in this situation with that many fx in project you might need to bypass all fx while recording

there's a script reallm (low latency monitoring) that can do it automatically.
https://forum.cockos.com/showthread.php?t=245445

[barbaroja]

Just tried more stuff. Seems not to be related to the number of FX but to the number of tracks that are routed to a certain folder (Deleted all unnecesary tracks for testing, in step 1). I am attaching a typical folder structure, console style, with sends. (yes I know I use lots of premade sends, just makes everything quicker). I also like to have my mastering chain off until the end of the process, for writing/mixing usually only js mid side encoder/decoders are used.

I will take 48% as the base scenario CPU RT usage, with track #20 enabled for monitoring and recording.

1. Delete all other tracks not in same level (ie: Busses). No change.
2. Delete all of the vocal sends (under vocal buss): CPU RT: 30%. 18% Reduction! Brought them back for next tests.
3. Take vocal sends out of the folder structure (any level of folder structure): No change. Bring them back.
4. Bypasing mid side processing: 8% reduction. (Big for a simple js decoder), def related to folder structure. Enabled again.
5. Going up (armed track) one folder level (sends (from 3 to 2): 25% CPU RT. 23% reduction!
6. Going up another level (from 2 to 1): No change from before.
7. Going to level 0 (no folder): No change.

As a reference, if I delete everything and only leave that track armed, CPU RT goes to 22%.

Dunno. Hope something can be done. Seems weird.

Edit: Added Screenshot. FX number is reduced drastically.

[Marco0402]

Hey,
I was really looking forward to the Update. It did in fact help, but not to the extend I was hoping for.
I run a pretty Folder heavy sorta version on Brauerizing. With a high plugin count the performance is getting worse with trying to increase the buffer size. Running rather smoothly with 512 at first. at some point I want to up it to 1024 to get a little more headroom back. But then Audio starts to lag.
I'm running a pretty good machine (MacBook M1Pro, reaper running native as well as only M1 native plugins).
I just wish that I could up the buffer size to unlock more processing power when in need

[ELBAJISTA33]

Originally Posted by Marco0402

Hey,
I was really looking forward to the Update. It did in fact help, but not to the extend I was hoping for.
I run a pretty Folder heavy sorta version on Brauerizing. With a high plugin count the performance is getting worse with trying to increase the buffer size. Running rather smoothly with 512 at first. at some point I want to up it to 1024 to get a little more headroom back. But then Audio starts to lag.
I'm running a pretty good machine (MacBook M1Pro, reaper running native as well as only M1 native plugins).
I just wish that I could up the buffer size to unlock more processing power when in need

I heard that latency issues are solved by going up to 250 unfortunately uses more CPU. This can be considered a problem, as it cannot be mixed to 1024 or 2048 without generating latency. I repeat, in version 6.79 I mixed to 2048 without any difficulty and using some Acoustic Audio ZL plugins. Hopefully this can be repaired. the exact same thing happens to me, I also use Brauerizing.

[Marco0402]

Originally Posted by ELBAJISTA33

I heard that latency issues are solved by going up to 250 unfortunately uses more CPU. This can be considered a problem, as it cannot be mixed to 1024 or 2048 without generating latency. I repeat, in version 6.79 I mixed to 2048 without any difficulty and using some Acoustic Audio ZL plugins. Hopefully this can be repaired. the exact same thing happens to me, I also use Brauerizing.

Thanks for your reply.
Do you actually mean a buffer size of 250 or 256? I always though one should always use either 64, 128, 256, 512, 1024...
Nice to hear you are using Brauerizeing as well.
I'm still fine tuning my template. If your interested, we can talk about your version of Brauerizing in a private message or another thread. Would be interested how you approach it in reaper

[ELBAJISTA33]

Originally Posted by Marco0402

Thanks for your reply.
Do you actually mean a buffer size of 250 or 256? I always though one should always use either 64, 128, 256, 512, 1024...
Nice to hear you are using Brauerizeing as well.
I'm still fine tuning my template. If your interested, we can talk about your version of Brauerizing in a private message or another thread. Would be interested how you approach it in reaper

yes 256

[barbaroja]

Something did change in Reaper, now it behaves better when sending all mastering plugs to Master track than cascading through multiple tracks (did test before and had to do that to be able to run).

Did a new test, removed mastering plugs, sent to master (another project). All good.
But, just the fact of using a premaster track (I read quite a few of us do) ups the CPU RT a good 15%! That is a lot.

Hope the devs notice this as it is pretty high, for any standard.

[barbaroja]

Cockos should hire me lol.

Using process lasso, in performance mode. Impressive difference to say the least. Goes from 40% (under a 5th folder) to 25% no matter if under a folder or not.

Truly remarkable!

Ableton live seems not to care whether folders are used or not so, it can be done!

[sockmonkey72]

Originally Posted by barbaroja

Cockos should hire me lol.

Using process lasso, in performance mode. Impressive difference to say the least. Goes from 40% (under a 5th folder) to 25% no matter if under a folder or not.

Truly remarkable!

Ableton live seems not to care whether folders are used or not so, it can be done!

I have no idea how to go about reproducing this based on this description. Maybe post a project?

[Marco0402]

A little update...
I seem to get around the buggy performance with higher buffer settings with playing around with the Buffering Behaviour (setting it to 0 - Relaxed).
Still probably not the best solution, but til an reaper update in the future will fix the performance issue it should be workable.
But also haven't tested it long enough with the Behaviour setting to be 100% certain that it could be an temporary fix.