Reaper audio dropping with high latency plugins on folders

[Eisenspalter]

Originally Posted by jackmilas

Plugins that introduce high latency cause audio to drop / stutter when they are inserted on parent folder tracks.

Here is a video (unlisted YouTube) presenting the problem.
https://www.youtube.com/watch?v=Z0Ke...ature=youtu.be
Also two of my friends told me they've been having similar issues with folders, so it looks like it's not related to my specific configuration.

+10000
@Cockos Can't you finally tackle this annoying topic? As soon as you use multiple compressors in a row, the crackling begins. Isn't it the most important thing for a DAW to produce a clean output?

[kris.audioplanet]

I just tried the latest beta and it looks like this has been improved a lot! No more crackling and somehow even my UAD plugins are behaving better

[fwd0120]

Originally Posted by Ideosound

v6.09+dev0428 - April 28 2020
+ Delay compensation: FX chains can be set to compensate delay Per-FX, Per-chain, or not at all
+ Delay compensation: in record input FX and monitoring FX, when not in ignore delay compensation mode, dry signal is now kept synchronized to wet signal (change from previous behavior)
+ Delay compensation: master FX chain can be set to compensate delay at the hardware-send level

Wow, as somebody who has tried to use reaper as a live mixing platform, this is a real game changer! Even a big plus for live monitoring in the studio. Now only if we could get PDC down below the block size (like if a plugin reports 3 samples of delay it wouldn't round up to the block size, a la other daws like Ableton). That would be an absolute dream. This is why I keep coming back to Reaper!

[Joe90]

Originally Posted by fwd0120

Wow, as somebody who has tried to use reaper as a live mixing platform, this is a real game changer! Even a big plus for live monitoring in the studio. Now only if we could get PDC down below the block size (like if a plugin reports 3 samples of delay it wouldn't round up to the block size, a la other daws like Ableton). That would be an absolute dream. This is why I keep coming back to Reaper!

That is exactly what it does when you use the 'per chain' PDC setting. It stops rounding up those low latency plugins to the block size and just calculates the total amount for the full chain, just like other DAW's.

[mlprod]

Originally Posted by Joe90

That is exactly what it does when you use the 'per chain' PDC setting. It stops rounding up those low latency plugins to the block size and just calculates the total amount for the full chain, just like other DAW's.

He means no block size round ups at all.

However I much prefer the roundup since I think (not know) that this gives a stability and less erros in latency due to errors in plugin reported latencies.
Seems like an extremely fundamental way reaper handles these things so I think (not know) any hopes for another way of doing this is...hopeless.

[the19thbear]

So basically, it's fixed in the newest version?

[mschnell]

Originally Posted by fwd0120

as somebody who has tried to use reaper as a live mixing platform, this is a real game changer!

IMHO, for Live usage in most cases it's better to switch off PDC completely.
-Michael

[Ideosound]

Originally Posted by the19thbear

So basically, it's fixed in the newest version?

Only the pre-release versions have this option currently.

[the19thbear]

Ok. Will wait for official release then. Please post here once it is a part of the official release

[faun2500]

Oh thank you!. I am having exactly this problem with ozone 9.Also disabling PDC in Ozone 9 stops the buffer issue but makes massive latency.

Glad I found this thread! Going to take it all out the folder track. BUT, why is this still happening?

[faun2500]

Originally Posted by faun2500

Oh thank you!. I am having exactly this problem with ozone 9.Also disabling PDC in Ozone 9 stops the buffer issue but makes massive latency.

Glad I found this thread! Going to take it all out the folder track. BUT, why is this still happening?

Looks like I spoke too soon! Removing the folder track does nothing to sort the crackling sound when I press stop. If I turn Ozone 9 PDC OFF I have no problem but the latency is so huge it's impossible to work!

This really has become a major issue for me now.

[the19thbear]

Any news on this? Super annoying (but there is a work around, it just requires some annoying work).

Any news on when the fix will be implemented?

Thanks

[mlprod]

https://forum.cockos.com/showthread.php?t=247379

[the19thbear]

Sorry, but I dont really understand
Has it been fixed in that pre release version?

Thanks

[jannikthary]

having the audio crackling issue for years now unfortunately.
I followed several advices I found in threads like this to improve the performance, e.g. using traditional sends instead of parent folder sends, disabling PDC for plug-ins on my MASTER bus (Not the final Master Bus in reaper), changing the buffer size, etc.

I manage to work around this problem somehow, but I'd like to at least try to understand the process how Reaper handles it's delay compensation or what ever causes this issue, so I might be able to set my settings more accurate and not being lost during a session the problem occurs.

Is there a source explaining this easily?
I'm not thinking of spending hours to understand every little detail. More like an overview.

I'm sorry for not giving a more accurate description of the problem, as I'm not that much into the whole IT behind this.
I appreciate the afford of this helpful community a lot! Thanks for all the effort behind this whole movement.

[faun2500]

A big problem for me was Sonarworks reference. There is a widely reported problem with crackles using this software on windows. After removing it it's help with crackles.

[AtmanActive]

Recently, Reaper got new PDC (Plugin Delay Compensation) modes for each track and for the Master Track as well. The Master Track has one more unique PDC mode not available on other tracks.

In my personal experience, in these latest Reaper versions, the real-time CPU engine handles long FX chains much better on the Reaper's Master Track, than using a custom folder track that's processing the whole mix.

Try it out.
Experiment with it.
You can find it in the FX window of each track, pull-down menu Options->Chain PDC Mode. Keep in mind that Master Track has "Hardware output compensation" mode, other tracks do not.
Good luck!

[the19thbear]

DELETED

[Loulou92]

Sorry, maybe a dumb question but what does the PDC on the master track special mode changes ? I don't understand how and why it's compensated. Why would you compensate it, as it's "everything". You'd compensate it to "nothing" as I understand it... This is so confusing....

[mschnell]

The compensation is done at the point(s) of mixing signals together.

So supposedly the master track itself is not affected.
-Michael

[mks]

I'm still having issues with this and it's getting really hard to deal with. Been tearing my hair out in another thread trying to figure this out and why it has recently gotten worse. This might partially be due to workflow though and the fact that I'm increasingly making use of folder tracks for subgrouping, group processing and inter-group processing and for ease of stem rendering come mix/render time for deliverables.

A few points I've noticed:
- the primary issue being premature crackling at low CPU useage
- especially on starts/stops
- it also slows down things like GUI mute/solo response. Sometimes taking over a second or two to switch (accompanied by loud crackling)
- this mute/solo issue is also inexplicably present on tracks outside of these folder at the "root" level.
- this is all related to PDC. It seems that disabling it for bus processing, also reduces the issues above.

What's going on here? If it's lack of parallelization due to bussing, I can (very reluctantly) change my workflow. But why is it affecting mute and solo, causing gui lag and all these intermittent noises (on mutes/solos/starts/stops) when the session actually runs at a reasonable CPU useage once it gets going?

[ferropop]

Originally Posted by mks

I'm still having issues with this and it's getting really hard to deal with. Been tearing my hair out in another thread trying to figure this out and why it has recently gotten worse. This might partially be due to workflow though and the fact that I'm increasingly making use of folder tracks for subgrouping, group processing and inter-group processing and for ease of stem rendering come mix/render time for deliverables.

A few points I've noticed:
- the primary issue being premature crackling at low CPU useage
- especially on starts/stops
- it also slows down things like GUI mute/solo response. Sometimes taking over a second or two to switch (accompanied by loud crackling)
- this mute/solo issue is also inexplicably present on tracks outside of these folder at the "root" level.
- this is all related to PDC. It seems that disabling it for bus processing, also reduces the issues above.

What's going on here? If it's lack of parallelization due to bussing, I can (very reluctantly) change my workflow. But why is it affecting mute and solo, causing gui lag and all these intermittent noises (on mutes/solos/starts/stops) when the session actually runs at a reasonable CPU useage once it gets going?

I experience all the same stuff, and use folders for all the same reasons.

It's specifically bad with (ironically) plugins that you think "I'll just use ONE of these across a folder, and that'll be more efficient!" but it actually does the opposite. Soothe / Gullfoss come to mind - the broad-strokes plugins that generate high PDC somehow are more efficient if you use multiple instances across many tracks rather than on a folder.

Some things that have helped :

Set your audio thread priority to Relaxed.

If you send from a folder to another folder, try to send from its individual subfolders rather than the highest parent. Example, if you send your VOX bus to INST Sidechain (to make space with TrackSpacer or Soothe SC), instead of sending the entire VOX folder try sending the LEADS folder, and the HARMS folder, etc. For some reason this has worked for me.

Use the new auto-plugin disable stuff.

Controversially - set all your tracks to Send to Stereo Parent rather than ALL, to block the sidechain signals also sending to their parent needlessly. MPL made me a neat script (see ReaPack, search "MPL" and "Stereo", it should show up...). I run it on all tracks any time I open an old project, and it corrects what I think is an issue. And in my default template I set the default to always send to Stereo Parent so that this issue never happens again.

Lastly - when I have to use it I've just gotten into a habit of disabling the folder processing until render time, and just learning to predict the effect it'll have when you can't audition in realtime.

It's really unfortunate dealing with this stuff, meanwhile the CPU meter is sitting at like 5%, and you're rocking a i9-10900k with 64gigs RAM, but hopefully it gets looked at eventually.

[ferropop]

Oh another little trick - if doing the VOX to INST 3/4 sidechian thing I have also just rendered the entire VOX bus to a new track, and just stuck that track inside the INST bus, outputting to 3/4 rather than 1/2. It achieves precisely the same effect as a sidechain send, with the obvious downgrade of having to render a new version every time you make a change to your VOX bus. But because it's just a flat file, there's no crazy PDC calculations happening between folders.

[mks]

This seems to be the bug of bugs! Hugely impacting real useability and workflow. Nearly a deal breaker for me if I wasn't so dedicated and loving the rest of Reaper. I really hope this gets looked at asap.

I have tried recreating all of this by nesting folders with varying degrees of plugins requiring PDC at each level, but can't quite get this recreated in a test scenario. My current conclusion is that this folder processing issue is also tied to Anticipative processing (as noted below) and only comes up when there are varying amounts of anticipative buffering. I will attempt to recreate this next.

A few more recent comments since these last responses and some testing I've done since then:
- The thread priority "behaviour" setting has a huge impact on this! Wow, thanks @ferropop This is getting a little more useability out of the current condition.
- I wonder if relaxing this setting points to the potential that other things on a system are causing issues? Like other process interrupts conflicting with the more aggressive settings in Reaper. I was about to tear down my system this weekend before finding other people with this long standing issue.
- I haven't fully thought this one through yet, but: Overall audio buffer size has an impact here as well obviously. Though it seems to scale significantly more than the value increase itself. For instance going from 512 to 1024 causes significantly more mute/solo latency than would seem expected. Almost as if compensation for this buffer occurs multiple times in a plugin chain.
- And obviously this is all PDC related BUT tied to Anticipative processing. Turning off anticipative gets rid of the GUI latency and mute/solo type issues. Which doesn't quite make sense to me since the plugin latency doesn't change, yet Reapers effort in pre-buffering causes all kinds of delays (even when stopped). This feels really strange and as if something is quite right with how this works.

[ferropop]

Oh yeah, definitely play with some of the buffering settings.

If you're using fast SSDs, you can literally disable Media Buffering for example. and I have the Anticipative Buffering setting to half the default.

I started just halving everything and testing, and continuing this way until something got ugly, and finally settled on the optimal settings that gave super snappy response times with reasonable lack of crackling.

[mks]

Absolutely. Just putting the system back together now to continue work for next week, so we'll see how it goes. Still seems strange that we have to optimize to his extent to get around this.

What seems most significant is not that it is being "foldered" in the first place nor even where there is processing on those folders (with PDC disengaged), but that these problems occur ONLY when PDC is engaged for those folders.

That and all these other strange behaviours (such as latent GUI when stopped, etc.) seem to be clues towards something being amiss.

Hopefully someone that knows the inner workings can let us know why we can't effectively process folders with PDC, and hopefully find a way to solve this. It's a pretty important way of working these days for me. Not just creatively but also in terms of efficiently running this as work.

[dyross]

To the folks that have been following this issue for a while - does anyone know if this would lead to / worsen the loop glitch issue:

https://forum.cockos.com/showthread.php?t=265724

Similarly, is this why anticipative FX isn't working for me except on ridiculously high settings:

https://forum.cockos.com/showthread.php?t=275295

Thanks!

[dyross]

Apologies for the double post - have the developers ever acknowledged this issue?

[mks]

I'm not sure, but this is a tremendous issue. I hope someone can look into this.

The title of this thread is very accurate. I've just done some testing on sessions that were nearly unuseable with glitching, stutters on start/stop and mute/solo latency. Removing these from folders and routing via sends through the exact same signal path completely removed the issues. So the behavior very strongly implies that something about folders is very broken. Unfortunately working without them is a huge workaround and is a big issue for the way I work (and truthfully for why I switched to Reaper a few years ago).

The following factors are somehow related to causing Reaper to crawl (to a halt in some cases):
- Tracks within folders (not yet sure what about these tracks causes this other than they may be nested, or have varying levels of required PDC)
- DSP on the folder itself
- PDC of this DSP is enabled (disabling it removes the issue)
- Anticipative processing also needs to be enabled

Factors that impact the severity of this issue are:
- audio buffer size
- audio buffering thread priority "behaviour": this one is perhaps a clue as to some threading issue
- Anticipative "render ahead": seems to point to the fact that there may be something amiss with the relationship of Anticipative and PDC

I really hope this gets looked at. In it's current state, folder use is very limited to the point that I now have to avoid using them just to make it through mix and production sessions. Functionality that is normally key to the way I like/need to work and slows down workflow tremendously.

Thanks everyone and thanks to the developers

[ferropop]

Originally Posted by mks

I'm not sure, but this is a tremendous issue. I hope someone can look into this.

The title of this thread is very accurate. I've just done some testing on sessions that were nearly unuseable with glitching, stutters on start/stop and mute/solo latency. Removing these from folders and routing via sends through the exact same signal path completely removed the issues. So the behavior very strongly implies that something about folders is very broken. Unfortunately working without them is a huge workaround and is a big issue for the way I work (and truthfully for why I switched to Reaper a few years ago).

The following factors are somehow related to causing Reaper to crawl (to a halt in some cases):
- Tracks within folders (not yet sure what about these tracks causes this other than they may be nested, or have varying levels of required PDC)
- DSP on the folder itself
- PDC of this DSP is enabled (disabling it removes the issue)
- Anticipative processing also needs to be enabled

Factors that impact the severity of this issue are:
- audio buffer size
- audio buffering thread priority "behaviour": this one is perhaps a clue as to some threading issue
- Anticipative "render ahead": seems to point to the fact that there may be something amiss with the relationship of Anticipative and PDC

I really hope this gets looked at. In it's current state, folder use is very limited to the point that I now have to avoid using them just to make it through mix and production sessions. Functionality that is normally key to the way I like/need to work and slows down workflow tremendously.

Thanks everyone and thanks to the developers

Agreed, I've completely adapted my workflow and track organization to suit the "least amount of aggrivation for maximum benefit" scenario in Reaper. The benefits are so tremendous, especially in terms of stem rendering and sidechaining collections of things to other things, that it's worth forcing into a useable workflow.

Would be so so good to have this looked into a bit when there's a moment. Reaper otherwise seems to have the the most efficient audio engine out of any DAW - but definitely something feels off with folders.

[dyross]

Agreeing with the other folks on this thread - I basically have to turn off anticipative FX because folders (and PDC-heavy FX like soothe2 on those folders) are so key to my workflow.

[dyross]

Actually, are we sure this only happens with folders and not with regular sends? There's conflicting info on this thread.

In my project, I have a parent folder "Mix Sum" (with master send off) with only 0 PDC FX, which sends to a final non-folder track "Mix Bus" with heavy PDC FX and master send on.

When I turn on anticipative FX, playback is impossible (100% glitched and stuttered).

However, if I turn off the FX with non-zero PDC (even PDC == 1) and leave on other FX on the "Mix Bus" track, playback works perfectly well with anticipative as small as 50 ms.

Note I'm running with block size 2048 on Mac.

In this case, it doesn't seem like the folder is the issue but any root-level FX with non-zero PDC.

I can do a more exhaustive test later.

[mks]

Interesting dyross. Does this happen when nothing is sending to the master bus? But perhaps also placing audio on the master bus track to make sure it’s actually processing audio.

It would be interesting in your case to make sure there is correlation between bussing and that it’s not just a hard PDC, comparability or other issue for the plugins on that track. You’ve probably already done this, but wanted to say it out loud.

My case showed a clear and significant difference between folders and send bussing with all other factors equal.

If I have your plugins, it’d be fun to test your session if you’d want to share.

[mks]

I’d love to build a little bug test session to try and track down this specific behavior using only stock plugins. Perhaps something we can share to test as well. Since this seems someone related to thread management, can someone recommend a high CPU use stock plugin. I’m using reaFIR to induce high PDC but can’t get there without high CPU useage as well. And who knows what else :P

[dyross]

Originally Posted by mks

I’d love to build a little bug test session to try and track down this specific behavior using only stock plugins. Perhaps something we can share to test as well. Since this seems someone related to thread management, can someone recommend a high CPU use stock plugin. I’m using reaFIR to induce high PDC but can’t get there without high CPU useage as well. And who knows what else :P

There’s a jsfx for adding delay. Don’t remember what it’s called as I’m afk. You can also easily build your own jsfx for this.

I’ll send some code / the name when I get back. I do think one is stock so if you filter for cockos you might find it.

[mks]

Thanks. That’d be useful too to test those variables! Right now I’m just trying to drive up multithreading use and need some plugins that require heavy lifting on that front (that I can share with the group).

[dyross]

Hi mks, I misunderstood your request. My ideas will help with PDC but not with CPU usage.

Can you try to oversample your plugins? As you probably know, Reaper supports oversampling up to 16x per plugin instance or per chain.

[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.

[dyross]

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 trst and somewhat toed to performance. but maybe we can go sonewhere with this.

Fantastic work with this. I hope the devs take a look as this is a very clear presentation.

[ferropop]

Thanks for doing this, I've tried for years to articulate the specific situation but always with 3rd party plugins. You being able to show this using only stock plugins is (hopefully) tremendously helpful to the devs.

edit : if you include Sends between the various configurations you tested here, anything of note? For me it is the biggest culprit, to the point of completely changing my workflow to avoid this seemingly-innocuous but deadly combo.