Reaper audio dropping with high latency plugins on folders

[ferropop]

(you can now see why I petitioned for years to remove automatic "Send 3/4+ to parent" lol)

[mks]

Unfortunately the issue seems to be dependent on multiple interrelated factors, making this a tricky one to test with one simple test. But I too have to deal with this everyday on every project after a certain point.

I had a moment to create another test project using only stock plugins. This time a little simpler than the last one I posted. I don't want to confuse this thread by reposting my previous notes an observations, but I'll note a few recent clarifications here as well. So here goes:

The interelated factors seem to be:
- PDC compounding through the use of folders.
- a moderate load on the CPU to stress what seems to be the threading process. This is what is so variable about this and why the exact session may need to be modified in order to see a similar limit. Also note that doing this with stock plugins is difficult since none of them are really that intensive until oversampled or used in unrealistic ways. This occurs very naturally with common plugins that are a little more intensive and need PDC. Requiring no "simulated" behaviour to get there.
- Anticipative on

This test project consists of:
- two folders, each with children. No media is necessary.
- The folder titled GP1 consists of members 'A' that contain an identical set of processing. Set to 4x oversampling to drive up resource use.
- The folder titled GP2 consists of members 'B' that contain an identical set of processing. Set to 16x oversampling to drive up resource use.
- each GP master has a plugin chain as well.

Things you may need to do:
- depending on the host system, duplicate the children in GP2 until glitching or sluggishness of mute/unmuting occurs.
- most importantly note that we're not increasing things until CPU or RT CPU hits any sort of maximum. For instance, this occurs for me at aroudn 30 percent load. We are NOT testing maximum CPU performance.
- You will often need to start/stop for changes to take effect for some reason.
- Once you have hit some glitching, set the full chain PDC compensation for GP2 to off. The problem disappears entirely. Pointing to some issue with PDC when used in any common scenario.

Other things that can help since turning off PDC is usually not a viable option:
- Anticipative look ahead increase: though this only shifts the onset of the issue to a bigger required load.
- Thread behaviour decrease to moderate: again this is also simply a workaround and only reduces the effect. Though interestingly, this might point to some relation between threading and PDC calculations. Though increasing this to 'aggressive' can help the simulation for anyone that knows what's going on under the hood.

Hope this helps. This is a long thread for an issue that has interlated factors. Hopefully we can all patiently help each other identify the problem.

[mlprod]

Can it not be simply something with how you have structured your projects with dependencies (ie plugins having to wait for others finshing processing) in a very complex routing config when using very CPU heavy combined with oversampling etc etc etc?

I suspect if the devs saw something here Justin would have already chimed in, but of course that's just a speculation.

[ferropop]

Originally Posted by mlprod

Can it not be simply something with how you have structured your projects with dependencies (ie plugins having to wait for others finshing processing) in a very complex routing config when using very CPU heavy combined with oversampling etc etc etc?

I suspect if the devs saw something here Justin would have already chimed in, but of course that's just a speculation.

In my situation the CPU sits at like 5%, and behaves identically to the test cases others have shown - RT skyrockets, and impossible to use levels of crackling.

[mlprod]

Originally Posted by ferropop

In my situation the CPU sits at like 5%, and behaves identically to the test cases others have shown - RT skyrockets, and impossible to use levels of crackling.

I think that might happen when you sort of "trip the wire" of what the single thread can cope with.

[HighVoltage]

Originally Posted by mks

I've setup a quick testing session here and have done the following:
- using all stock plugins and no media. Plugins chosen due to high latency and CPU useage.
- oversampling used to inrease CPU useage to a more realistic level.
- multiple folders with nested folders (nesting below one level has little impact, see below)
- many tracks and folders (specifically the latter) with significant PDC required
- increased thread "behaviour" to very aggressive to exaggerate the behaviour. This one isn't very scientific but seems to be the signficant factor that all this is pointing towards. Unfortunately on real sessions, setting this to it's lowest setting does not make the issue go away to a satisfactory level, but simulating this on a test session with stock plugins is a little more difficult without this "exaggeration".
- then observing the latency that occurs when muting and unmuting things as well as the glitching that occurs. This test presents relatively minor issue when "exaggerated" but hopefully others can see and test this.

My observations so far:
- This has something to do with thread performance with folder tracks that require PDC. All three are in play together.
- Increasing Thread behaviour preference increases the apparence of the problem, which seems to point that the issue lies in there somewhere.
- also related to PDC since turning off PDC for top level folders as well as folders one level beneath reduces the problem.
- Testing without CPU load and just PDC factors however does induce this problem, neither does moving all items to root level. It's both together.
- Does not seem to be related to folder nesting depth, since moving all folders to just one level deep causes the same behaviour.
- Increasing the number of PDC/CPU hungry items within a folder increase the issues (higher gui latency and more glitching), even when completely reasonable CPU limits.
- disabling anticipative (if possible due to RT useage) also removes the issue. Possibly tied to the changes in required track level PDC.
- seems like this has somethign to do with how it calculates the total required PDC of foldered tracks. Creating some kind of congestion on how this dsp is threaded.

Super basic test and somewhat tied to performance, but maybe we can go somewhere with this.

Downloaded your test project and could reproduce the loooong crackling issue when muting the ALL track and then unmuting.
You have to wait a few seconds, the longer you wait in mute mode, the longer the crackling.

I have modified your project, and removed all the ReaFirs, and replaced them with Reainsert. It's even better, casue Reainsert uses ZERO CPU, it doesnt process audio, just adds PDC, and you can write in yourown number.
So i gave it a 1500 sample delay.
This way it exaggerates the problem 10 times, while even removing CPU stress of the equation.
I will further clean up your project to the bare bones until it still does this.

I'm at 128 buffer and Relaxed mode did not help.
However I had no problems with muting/unmuting sluggishness, just that crackling.

Another important note is that the crackling is instantly fixed if i press stop and play, (that resets Reapers buffer)

[ferropop]

^^ a similar thing happens if you have Loop Enabled, and draw a Loop Area while playback is happening -- I suspect Reaper is doing some kind of buffering related to the Loop Area, and because it's being drawn/modified in realtime something in the buffering is getting tripped up.

But it's the exact same audible result - the same style of crackling/freezing.

[HighVoltage]

Originally Posted by mks

Unfortunately the issue seems to be dependent on multiple interrelated factors, making this a tricky one to test with one simple test. But I too have to deal with this everyday on every project after a certain point.

I had a moment to create another test project using only stock plugins. This time a little simpler than the last one I posted. I don't want to confuse this thread by reposting my previous notes an observations, but I'll note a few recent clarifications here as well. So here goes:

The interelated factors seem to be:
- PDC compounding through the use of folders.
- a moderate load on the CPU to stress what seems to be the threading process. This is what is so variable about this and why the exact session may need to be modified in order to see a similar limit. Also note that doing this with stock plugins is difficult since none of them are really that intensive until oversampled or used in unrealistic ways. This occurs very naturally with common plugins that are a little more intensive and need PDC. Requiring no "simulated" behaviour to get there.
- Anticipative on

This test project consists of:
- two folders, each with children. No media is necessary.
- The folder titled GP1 consists of members 'A' that contain an identical set of processing. Set to 4x oversampling to drive up resource use.
- The folder titled GP2 consists of members 'B' that contain an identical set of processing. Set to 16x oversampling to drive up resource use.
- each GP master has a plugin chain as well.

Things you may need to do:
- depending on the host system, duplicate the children in GP2 until glitching or sluggishness of mute/unmuting occurs.
- most importantly note that we're not increasing things until CPU or RT CPU hits any sort of maximum. For instance, this occurs for me at aroudn 30 percent load. We are NOT testing maximum CPU performance.
- You will often need to start/stop for changes to take effect for some reason.
- Once you have hit some glitching, set the full chain PDC compensation for GP2 to off. The problem disappears entirely. Pointing to some issue with PDC when used in any common scenario.

Other things that can help since turning off PDC is usually not a viable option:
- Anticipative look ahead increase: though this only shifts the onset of the issue to a bigger required load.
- Thread behaviour decrease to moderate: again this is also simply a workaround and only reduces the effect. Though interestingly, this might point to some relation between threading and PDC calculations. Though increasing this to 'aggressive' can help the simulation for anyone that knows what's going on under the hood.

Hope this helps. This is a long thread for an issue that has interlated factors. Hopefully we can all patiently help each other identify the problem.

This test is even better. It already loaded up crackling like crazy. I only needed the GP2 folder, deleted the rest.

Here the Reainsert trick is again useful: (dont forget to set the insert to 100% dry to hear the audio through)
https://prnt.sc/CNGyUjrExXAG

There needs to be no processing on the folder track, just plain PDC, and it goes haywire.

[ferropop]

Thanks to everyone putting in the time to isolate this. If it's just a small oversight or tweak on the devs' part (fingers crossed!) it would have unbelievable impact to have this smoothed out !!!

[ScuzzyEye]

Originally Posted by HighVoltage

You have to wait a few seconds, the longer you wait in mute mode, the longer the crackling.

The mute/unmute thing was really puzzling to me. When I was having this type of problem, it made mixing really difficult. Having to wait seconds when changing the solo state of tracks makes A/Bing impossible.

I wondered why that in particular caused so much trouble. Does Reaper change the whole song's PDC when one track that needs a lot of compensation gets muted?

[HighVoltage]

Originally Posted by ScuzzyEye

The mute/unmute thing was really puzzling to me. When I was having this type of problem, it made mixing really difficult. Having to wait seconds when changing the solo state of tracks makes A/Bing impossible.

I wondered why that in particular caused so much trouble. Does Reaper change the whole song's PDC when one track that needs a lot of compensation gets muted?

Do you guys have the "Do not process muted tracks" enabled?
https://prnt.sc/vNNs1kPh9aRe

Cause that is the first thing you should turn off. It might cause most of your muting issues.

[gelbfinger]

Originally Posted by mks

Unfortunately the issue seems to be dependent on multiple interrelated factors, making this a tricky one to test with one simple test. But I too have to deal with this everyday on every project after a certain point.

I had a moment to create another test project using only stock plugins. This time a little simpler than the last one I posted. I don't want to confuse this thread by reposting my previous notes an observations, but I'll note a few recent clarifications here as well. So here goes:

The interelated factors seem to be:
- PDC compounding through the use of folders.
- a moderate load on the CPU to stress what seems to be the threading process. This is what is so variable about this and why the exact session may need to be modified in order to see a similar limit. Also note that doing this with stock plugins is difficult since none of them are really that intensive until oversampled or used in unrealistic ways. This occurs very naturally with common plugins that are a little more intensive and need PDC. Requiring no "simulated" behaviour to get there.
- Anticipative on

This test project consists of:
- two folders, each with children. No media is necessary.
- The folder titled GP1 consists of members 'A' that contain an identical set of processing. Set to 4x oversampling to drive up resource use.
- The folder titled GP2 consists of members 'B' that contain an identical set of processing. Set to 16x oversampling to drive up resource use.
- each GP master has a plugin chain as well.

Things you may need to do:
- depending on the host system, duplicate the children in GP2 until glitching or sluggishness of mute/unmuting occurs.
- most importantly note that we're not increasing things until CPU or RT CPU hits any sort of maximum. For instance, this occurs for me at aroudn 30 percent load. We are NOT testing maximum CPU performance.
- You will often need to start/stop for changes to take effect for some reason.
- Once you have hit some glitching, set the full chain PDC compensation for GP2 to off. The problem disappears entirely. Pointing to some issue with PDC when used in any common scenario.

Other things that can help since turning off PDC is usually not a viable option:
- Anticipative look ahead increase: though this only shifts the onset of the issue to a bigger required load.
- Thread behaviour decrease to moderate: again this is also simply a workaround and only reduces the effect. Though interestingly, this might point to some relation between threading and PDC calculations. Though increasing this to 'aggressive' can help the simulation for anyone that knows what's going on under the hood.

Hope this helps. This is a long thread for an issue that has interlated factors. Hopefully we can all patiently help each other identify the problem.

Thanks Mks for putting this together. Running your test project on my system gives the same crackling results just after adding two more additonal tracks in the GP2 folder. And yes, turning PDC compensation off makes the crackle go away.

Mac book pro m1 16GB Ram CPU arround 25% RTCPU arround 10%

[ScuzzyEye]

Originally Posted by HighVoltage

Do you guys have the "Do not process muted tracks" enabled?
https://prnt.sc/vNNs1kPh9aRe

Cause that is the first thing you should turn off. It might cause most of your muting issues.

It was actually worse with this enabled. If the tracks were still processed, but silent muting and unmuting didn't have a problem. That's what made me wonder if when Reaper stops processing a track it does something the the PDC counts. It seems like muting a high delay track would cause the entire buffer to emptied and then the anticipatory rendering would have to go back through everything, and the project would grind to a halt.

(Disabling anticipatory rendering seemed to improve the buffering issues, but for most projects took the CPU load higher than I could run in real time, so I couldn't disable a that either.)

I'm one of the few no longer suffering from this problem, but I think it's just because I have enough CPU power that changing the threading priority keeps my head above water. I may still one day end up with a song that exceeds the extended limits I found with that setting.

[ferropop]

Yeah I don't find the "Do not process muted tracks" to have a particularly large effect.

[the19thbear]

I'm really hating this bug. My session swith a lot of acustica audio plugins (high latency), just makes my session unplayable even htough i am only using 40% of my cpu.

THe only fix for now, is to not use group tracks?And manually routing instead?

Really hope reaper people will fix this soon.

[ScuzzyEye]

Originally Posted by the19thbear

THe only fix for now, is to not use group tracks?And manually routing instead?

I'm pretty sure I was able to trigger it with sends (albeit with send to parent disabled).

I had a mastering template where I was trying to avoid nested folder tracks, so I put the imported song on a track. That had volume automation, along with some EQ and general tone shaping effects. That track was set to not send to parent but to track 2. Track 2 had Gullfoss (the trouble maker), and some stereo width adjusting effects. Finally that sent to track 3, which had the limiter on it. Track 3 did have parent send enabled so it would go to the master. The master had no inserts.

That whole setup was an attempt to still keep my workflow modular (I could swap out whole FX chains based on what was needed), while avoiding nested tracks. It didn't help. The send to send to send seems to be the same as folder in folder.

(I'm just posting these different configurations I tried in hopes that someone sees a constant in the overlaps, and has a ah ha moment as to where the problem might lie.)

[the19thbear]

Do we have any devs looking in this thread? Has this bug been noticed?
It really breaking stuff for me.

[norbury brook]

Originally Posted by the19thbear

Do we have any devs looking in this thread? Has this bug been noticed?
It really breaking stuff for me.

it's strange Justin or Schwa haven't commented on this just to say either, it's a bug or it's just how things work due to 'x.y.z' etc.


M

[the19thbear]

Hmmm I guess the forum doesn't allow for tagging people? Otherwise we could tag them here.

Maybe the OP could change the headline, to something bug related to get more attention?

[px73]

Hey folks,

It's strangely comforting to know that it's not just me. ;-)

Presently working in a 114 track wide session. Processing on master, full of folders, however those are only ever one deep, and generally with processing on the parent and children. Folders tend to be FX, Drums, Guitars, Bass, Vocals and so on.. in most every project I work on.

I have been hating the demon scream of starting and stopping playback, muting or unmuting, soloing or un-soloing. The worst part of it is that it creates a lot of "enjoyment friction" in the mix process. I think that outcome is the most damaging.

This project has 220 FX, is 96k24 and is currently running at about 50% CPU and 40% RT CPU (post "fix"). The processor in this machine is a Intel Xeon E5 2660v3 at 2.6GHz. That's an old 10 core relic that I probably ought to update. 64GB RAM, all SSD. RTX2080Ti GPU, Lynx AES16e interface.

So after finding this thread, I conducted some experimentation in a setting by setting fashion - in some kind of an attempt to be scientific - and let's be honest, this feels like adjusting the performance of a muscle car by polishing different parts of the bodywork.

Here's what killed the demon for me and has clean playback - Thread Priority Highest (recommended) but Behavior at Relaxed. Media buffer default, prebuffer default - Anticipative enabled (unusable without) and render-ahead at 500ms, allowed on tracks without FX and tracks with open midi editors (no consequence in this project).

For me the setting with the greatest effect was the thread behavior. There is an expected half second delay on playback and stop, and also a delay on mute/unmute and solo/unsolo (i wish it was instantaneous of course). However, no wails of the undead which is much, MUCH more pleasant. What I do find unusual though is sometimes when soloing, it's not an instantaneous selection but seems to iterate groups, so when I solo the drum buss, I get drums up front with the bass buss for a fraction of a second before it's just the drums only. There's definitely some recalculation going on but I am not sure why this should be - if the system is selecting streams of data to pass through it's mix engine and not others.. what is there to recalculate other than updating an array of flags and letting the engine do it's thing? Who knows. I shouldn't be taking wild guesses at what's lurking under the hood or how it's masked/unmasked/selected/whatever.

By the way, I found no particular benefit to fiddling with PDC on the master, or anywhere else for that matter. Given PDC had to be done manually somewhere back in time, that I can even fiddle with this in this modern era feels quite uncomfortable.

I feel for the developers as what they have here is a seemingly infinite number of user case permutations all pointing toward a specific symptom. All differing architectures, implementations, setups, OS versions, interfaces, routings, sample rates, plugins and so on. What a nightmare.

Anyway, there's my 0.02 New Zealand Pesos worth of "contribution". Thank you for coming to my TED talk.

[ScuzzyEye]

Originally Posted by px73

There is an expected half second delay on playback and stop, and also a delay on mute/unmute and solo/unsolo (i wish it was instantaneous of course).

I don't know if it'll help with the solo/unsolo (mine seem to be pretty snappy with current config/project sizes), but you can try setting the prebuffer to under 100%. 25% (of 1200ms) seems perfectly fine for me. As long as you have a decent percentage of CPU time free the buffer will eventually fill all the way. Setting the prebuffer lower just allows playback to start sooner.

[px73]

Originally Posted by ScuzzyEye

I don't know if it'll help with the solo/unsolo (mine seem to be pretty snappy with current config/project sizes), but you can try setting the prebuffer to under 100%. 25% (of 1200ms) seems perfectly fine for me. As long as you have a decent percentage of CPU time free the buffer will eventually fill all the way. Setting the prebuffer lower just allows playback to start sooner.

Hey, thanks for the tip. I gave it a try as low as 10% and it definitely gets up and starts playing much faster - so much appreciated!

So here's a slightly different thing I just noticed regarding the time it takes to toggle solo and mute functions.

I have a US2400 control surface which works just great with Reaper - however - I have it configured to select track on mouse click which will cause the control surface to bank across (as it's addressed in multiples of 8) to show a bracket of tracks including the one you clicked on.

So what seems to happen is.. if I am soloing something that's "offscreen" as far as the control surface is concerned, reaper sends instructions to the control surface first, likely waits for the control surface to say something back to indicate it's updated, and only then does Reaper execute the solo or mute. If the object I am soloing or muting is "onscreen", it's much much faster.

So how about that - it seems control surface instructions are further up the queue than instructions to the audio engine. I find that a little bit odd. :-)

[mks]

Just a minor update regarding my experience with how this correlates to thread behaviour. Up until now, setting it to “most aggressive” has always led to the most bearable performance. But recent workflows have had me turning this down a few notches. Though this is likely because these projects are using more cpu intensive plugins. Which is at odds with aggressive threading, so not necessarily surprising. Just wanted to mention it though in case this helps anyone else struggling with this.

These last few weeks of intense work schedules have been a nightmare dealing with this though. I really don’t know what to do. It’s affecting almost every type of workflow I’ve developed at this point. Things feel broken but moving away from Reaper is not an option. Please help us Cockos.

[gelbfinger]

I just came to see if there was any development on this but as i see nothing seems to have happened.
So I did send a link of this thread to the suport email of the reaper.fm website. Did anyone else do this already ?

I hope someone on the other end will look into this and help us out.

I will post if I hear anything.

EDIT: I just realized that MKS did send an mail to the support time ago. Did you ever hear back ?

[Justin]

Sorry for the delay everybody -- got some fixes coming for this in the next build!

[ferropop]

Oh wow this legit made my weekend better!

[dyross]

Very excited to hear this!

[mks]

Amazing!! Thank you!!

Coincidentally, I just upgraded/replaced my workstation to brute force my way around this to a certain extent, but having these issues addressed will be a huge step forward! Especially if the bussing and latent gui issues get solved along with the performance issues. Very excited!

[ferropop]

What are you folks finding??? I'm having trouble breaking it!

[dyross]

Originally Posted by ferropop

What are you folks finding??? I'm having trouble breaking it!

Yeah, I'm finding it to be a revelation! Like I said in the dev channel, I have a project where I have to run anticipatory at 350 ms just to avoid pops and clicks. On the new build, I can run it at 5 ms flawlessly. Amazing!

[gelbfinger]

this will not just make my day ! it will make my NEXT YEARS !
I struggled with this issue for so many years already that i cant even believe it will be probably solved.
Never waited for an update so hard.

[ferropop]

I've felt so much more free to create sends/parallel/sidechain routing!

Have always dreamt of having a bunch of parallel-squashed tracks for each bus (drums, inst, bass etc) and with all the crackling it was just not feasible.

Have been able to do this flawlessly since the update, thank you so much.

[dug dog]

Originally Posted by ferropop

Have always dreamt of having a bunch of parallel-squashed tracks for each bus (drums, inst, bass etc) ....Have been able to do this flawlessly since the update, thank you so much.

Great news, indeed.

I got the impression that the devs weren't even paying attention to the issue and, then, suddenly, BAM !!!.

[norbury brook]

which update sorted this?



m

[ScuzzyEye]

Originally Posted by norbury brook

which update sorted this?

It's been testing in the +dev builds for a little while. Yesterday it was promoted to the current Release Candidate 6.80rc1. https://forum.cockos.com/showthread.php?t=279367

[norbury brook]

Originally Posted by ScuzzyEye

It's been testing in the +dev builds for a little while. Yesterday it was promoted to the current Release Candidate 6.80rc1. https://forum.cockos.com/showthread.php?t=279367

Ah thanks, I don't mess with pre releases but I'm glad it's been addressed.


Looking forward to the official release. TBH I didn't really suffer so much with this as I have a very powerful system but I'm glad it's been looked at and a solution has been found. Even with a powerful system any streamlining is a welcome addition.

M

[ferropop]

Originally Posted by norbury brook

Ah thanks, I don't mess with pre releases but I'm glad it's been addressed.


Looking forward to the official release. TBH I didn't really suffer so much with this as I have a very powerful system but I'm glad it's been looked at and a solution has been found. Even with a powerful system any streamlining is a welcome addition.

M

I'm on the most maxed-out CPU/RAM/SSD situation, it wasn't a processor issue it was apparently a bug (Justin mentioned this in a recent pre discussion).

[norbury brook]

Originally Posted by ferropop

I'm on the most maxed-out CPU/RAM/SSD situation, it wasn't a processor issue it was apparently a bug (Justin mentioned this in a recent pre discussion).

great, I don't tend to have lots of sub/folder groups so again it's not something I suffered from but i was happy to join the discussion and help out where I could in testing out the demo projects people sent.

Only reason i mentioned CPU was that some of the troublesome projects people posted ran fine for me.



M

[hexSPA]

For someone who's not been exactly following but still might notice a change:

v6.80 improves reaper performance in cases where high-latency plugins are used on folder tracks...

right? And is this to everyone's satisfaction so far? Are there any other settings that a user should change to get the most out of this new update?

I've also noticed issues but I thought a little summary here would clarify for me and anyone else who might want to search without wading through a three-year-old thread.

Thanks.

[ivsound]

Originally Posted by gelbfinger

this will not just make my day ! it will make my NEXT YEARS !
I struggled with this issue for so many years already that i cant even believe it will be probably solved.
Never waited for an update so hard.

What can I say, I've struggled with this for YEARS too.

I've always hit a wall due to the way I use folders and parallel processing.

So happy this is finally getting addressed, it has a huge impact on my daily mixing workflow.