Reaper audio dropping with high latency plugins on folders

[mks]

Originally Posted by ferropop

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.

I'll have to look into that too. I'd imagine the behaviour could be similar if it all comes down to a similar hierarchy of PDC compounding down a signal signal path. I did some testing of that earlier but mostly as an effort to solve the problem for current projects that I need to finish, so I wasn't quite methodical enough to comment on it.

[ferropop]

Here's another usecase that is currently crackly and unstable :

-you have DRUMS/BASS/INST/VOX folders

-you want to create 4 parallel compression/saturation channels DRUMSpll/BASSpll/INSTpll/VOXpll, and send to them from their respective groups

So a little section of faders for "parallel" stuff.

Currently this will probably be unusably crackly, at which point I abandon ship.


...weirdly if you were to use a compressor that has a Wet/Dry directly on the folder (rather than as a send) the performance is better. But then we're dealing with spread-out inserts rather than a tangible little group of "parallel" faders you can balance quickly.

Maybe that sheds some light of something else at play.

[mks]

Makes sense and this is also something I’d normally do a lot. Though truthfully this issue has me staying away from even doing things like this that I used to. I’ll do some testing too but this would face a similar “PDC compounding inside a top level folder” pattern that I imagine is very related (that’s a mouthful).

The inability to work with folders is a big problem and I really hope we can get some eyes on this to help us all out.

[dyross]

Originally Posted by mks

Makes sense and this is also something I’d normally do a lot. Though truthfully this issue has me staying away from even doing things like this that I used to. I’ll do some testing too but this would face a similar “PDC compounding inside a top level folder” pattern that I imagine is very related (that’s a mouthful).

The inability to work with folders is a big problem and I really hope we can get some eyes on this to help us all out.

Have you tried emailing their support with the repro steps / project?

[ferropop]

Sound on:

https://i.imgur.com/5m5f2Rs.mp4

Just want to post an example of what this is like.


All I'm doing is Muting / Unmuting the Vocal Bus (which sends to INST 7/8).
CPU and RT both sitting at 20%.

[ferropop]

No joke, I think this experience is worse than nails on a chalkboard. Trying to create and make hyper-specific audio decisions while this is happening is soul-destroying.

[ferropop]

Same project, this is how long it takes to open the MIDI Editor on a single kick drum track :

https://i.imgur.com/GieFpCH.mp4

i9-10900k with 64gigs RAM and the fastest SSDs.



I cross-posted this in the MIDI Editor - Why does it feel sluggish and tacked on thread (https://forum.cockos.com/showthread....55#post2645755) because these things Must be related!

[mks]

Totally. I see sluggish behavior in various areas too related to this. Is you thread behavior already as low as possible on all of these? When you increase it, does it be one even more unbearable? Might be hard to say since once it gets to certain point I have to bail out and start changing my session to get back to work.

[dyross]

Two questions:

Have the folks engaging on this thread ever emailed support at cocos dot com? If you can point to a clear bug with repro steps (and a sample project), I'd be surprised if you don't get engagement that way. Please correct me if that's a no no.

Second, have folks tried with anticipative FX off? I have it off because of this issue and things are quite a bit better. I have a complicated project with 2048 block size and it's usable, but not perfect. I do get some RT xruns from time to time.

Being able to run with small amount of anticipative to relieve my RT thread wold be best!

[the19thbear]

I sues quite a lot of high latency plguins on the master bus. I find when disabling pdc on each effect, it will help with the issue. I don't need PDC on the master bus anyway, since I route my live tracks straight to the outputs. Not through the master.

[ferropop]

Originally Posted by dyross

Two questions:

Have the folks engaging on this thread ever emailed support at cocos dot com? If you can point to a clear bug with repro steps (and a sample project), I'd be surprised if you don't get engagement that way. Please correct me if that's a no no.

Second, have folks tried with anticipative FX off? I have it off because of this issue and things are quite a bit better. I have a complicated project with 2048 block size and it's usable, but not perfect. I do get some RT xruns from time to time.

Being able to run with small amount of anticipative to relieve my RT thread wold be best!

I did a few years ago, didn't get a response. They have a trillion things coming at them though, but yeah this one's rough.

This said, I have no concept of if this same structure would completely crumble even worse in other DAWs and maybe we already have it really good!

[mschnell]

Originally Posted by dyross

There’s a jsfx for adding delay. Don’t remember what it’s called as I’m afk.

ReaPackk -> +/- delay

(and there are more of those)

-Michael

[mks]

I have just emailed support with details and links to this thread. Fingers crossed. The options for workarounds are becoming limited the more quickly and often I have to turn work around these days.

[ferropop]

https://youtube.com/shorts/yGSkvXBhTRg?feature=share

[mks]

Originally Posted by ferropop

https://youtube.com/shorts/yGSkvXBhTRg?feature=share

Crazy thing is that the behaviors I see begin to happen even with waaayyy lower RT CPU useage. Waiting several seconds to just mute something, glitching on starts/stops, etc. even below %40. Eventually getting to a stutter mess like this too though.

[dyross]

I just spent some more time on this today, and I'm not seeing exactly the same. behavior y'all are.

I sent the following message to their support (sorry, the images won't translate, but they are not essential):

---

Hello,

I have a somewhat complicated project (all MIDI) with many (third party) FX running on powerful mac in rosetta mode:

Screen Shot 2023-02-15 at 1.52.36 PM.png (shows M1 Max MBP w/ 64 GB RAM)

It works fine at 44.1k / 2048 block size, but my RT CPU is often around 75%, with occasional blips:

Screen Shot 2023-02-15 at 1.47.10 PM.png

It seems like "Anticipative FX Processing" is the right fix here, but unfortunately, I can't use it.

Screen Shot 2023-02-15 at 1.41.01 PM.png

As you can see from the image above, my routing setup is mildly complex: I have a "Mix Summed" parent folder, and then several other sends at the "Mix Bus" level before over to "MASTER". This is not for any particular reason, just trying to figure out what works for me (and some unsubstantiated concerns in the forums about folder vs. sends).

But, critically, when I turn on Anticipative, I get horrible constant crackles. Fascinatingly, I set "Ignore plug-in latency" on all FX chains at the red "mix bus" level, the issues go away and even with 50ms Anticipative, my RT CPU goes down to < 10%:

Screen Shot 2023-02-15 at 1.48.01 PM.png

This has to be a bug, right? It occurs even when I use a low CPU / high PDC plugin like ReaFir at the "mix bus" level, and doesn't occur at any other channel or "bus" level (high PDC plugins at, for example, "Instrument Bus" or "Drums Bus" don't have similar problems).

By the way, what is PDC actually doing at the "mix bus" level? Any drawbacks for turning it off?

I've included my project for reference, but, again, it has many third party FX, so not sure how helpful that'll be.

Thanks,
David

---

So, to summarize:

- I don't have this problem with anticipative off, but my RT CPU is getting dangerously high without it.
- When I turn on anticipative, high PDC *only* at the root level are causing problems. I don't see an issue at any other folder level.
- I also get the issue on my "mix sum folder" *and* also on "mix bus" when is a non-folder send from "mix sum folder", so the issue does *not* seem to be exclusive to folders for me. Anything at the root level is the issue.
- Turning off PDC at the root level solves the problem, with no noticeable side effects.

So, my questions are:

1. Can we reconcile what I'm seeing vs. what others are seeing in this thread? Do any of the workarounds (turn off anticipative, turn off PDC at root level) help others?
2. What is the need / effect of PDC at the root level in the first place?

[mks]

Thanks for the post and report Dyross. I actually perceive your experience as lining up pretty closely with the experiences I have seen. Though in your case the focus of observations is on anticipative processing. Which I’ve also noted as being one of a trio of inter-related factors that cause this.

So to answer your questions as I understand them:
1) Yes, absolutely. As I d also noted on a previous post, both of those features each remove the issue. Though sadly they aren’t useful workarounds for me. My sessions commonly require more processing than can be handled by a single RT thread. And disabling PDC is necessary for alignment.
2) If you mean master bus level, then you’re right, most environments wouldn’t require that. But for me root level refers to the top level tracks in a session. Which are often used as stem busses. And having PDC there would be critical to timing. Not to mention the various inter stem processes and things I typically have setup.

Have you had a chance to experiment with the thread “behavior” setting to see how that affects things? Changes affected by that seem to point to some issues with how threads are distributed when PDC is calculated for compounded (aka foldered) tracks in an anticipated processing environment. Quite a mouthful But it seems to be part of this inter-related trinity of factors. Not that we really have a solution or workaround to what feels like buggy behavior. Just things to experiment with and see if we can all help figure this out.

[dyross]

Hi there, thanks for the response. Would you mind clarifying a question I have around:

Originally Posted by mks

If you mean master bus level, then you’re right, most environments wouldn’t require that. But for me root level refers to the top level tracks in a session. Which are often used as stem busses. And having PDC there would be critical to timing. Not to mention the various inter stem processes and things I typically have setup.

I'm just naive here, so not pushing back, but what do you mean by this? Are the different stems going to different outputs to be rendered separately?

Are you seeing the issue at the stem level in addition to the master level?

The reason I ask is my project also has stem/group busses with some nesting (e.g. instruments -> background instruments -> guitars -> classical guitar etc.), but I'm able to run soothe2 fine on the "instruments" folder, but not on the master folder.

So trying to understand if there's something specific that causes a certain folder / level to have the issue, or if it's just about the summation of nesting / loading and falling off a cliff so-to-speak.

I didn't yet experiment with the threading because turning off PDC at master level seems to be a pretty good workaround for me at this point.

[mks]

Of course Mostly me being too wordy while trying to be specific

In my case, I use top level folder for two reasons:
1) For group processing of groups of instruments and/or spectrum ranges. A simple example being: vox lead, vox by, bass, drums, instruments hi, instruments low, etc. Often these send to each other in various ways.
2) I also try to simultaneously try to use them to organize things for when it comes to deliverables. Such as creating a tv mix versions, instrumentals, remix stems, live performance stems, etc. Though this is changing thanks to some wonderful scripts here

So probably similar to you. While also feeding master bus processing as well as multi levels of nesting beneath each.

This is where I’ve sorta stopped testing and where specific structure becomes a little tricky to pinpoint. A previous posts I made noted that nested depth doesn’t really ”change” things. Just that it has to exist at least one level below root and PDC-requesting-plugins are required at each of those levels. Strangely disabling PDC at lower levels doesn’t affect things where disabling it at the top level does. So yes, nesting seems necessary just not sure yet to what extent and where.

So I’d say your observations might still be in line with mine. Specifically: you’re seeing issues when there is nesting (and it would appear master bus counts here), and when there is a compounding of PDC calculations (where your master chain PDC disable seems to help).

Fun stuff

[dyross]

I think I get it, but let me just triple check

I have something like this:

Reaper Master Out -> Mix Bus Folder -> [Instruments Bus Folder, Drums Bus Folder, Effects Send Folder, etc.] -> [some further nesting, some individual instruments]

Note that "Mix Bus Folder" is *different* from "Reaper Master Out".

So, the top-level folders you're referring to, where do they send to? Something like my "Mix Bus Folder", or directly to "Reaper Master Out"?

If it's the latter, can you try adding a new "Mix Bus Folder", moving all FX from "Reaper Master Out", and turning off PDC on "Mix Bus Folder"?

(Sorry if this is a waste of time...)

[dyross]

Ah, and to answer your question directly:

When I turn PDC back on, but move to most relaxed thread setting, the issue is improved, but still pretty terrible. It does seem to be worse the more aggressive the thread setting, but no setting is passable for me, and I prefer to turn off PDC (at root level).

[gelbfinger]

i just wanna say thank you ! this bug is something that bothered me for a long time and i never understood what it was. Thanks to this thread I could finaly work arround it.

i followed some of the advices from this thread and applied them:

- moved Mix Bus FX to MAIN out (made a difference and improved)
- set thread priority to relaxed (further improvment)
- got rid off my beloved folders and used busses instead (helped big time)
- i also did freezed one track cause it hogged PDC (Izotop RX via Rosetta)

(Reaper 6.75. Mac OSX 12.6.3 on M1 MacBook Pro, Apollo X4)

[mks]

My “top levels” feed Reapers master out. Typically with processing there. As well as monitoring effects too. Though this bug is reproducible without either of those in play at all. I’ll test nesting them into a master bus folder to be thorough, but it seems like it’s a compounding issue regardless of how many levels deep. As soon as you have various amounts and depths of PDC, Reaper has increasing difficulty in assigning that processing without audible or gui glitching.

Originally Posted by dyross

I think I get it, but let me just triple check

So, the top-level folders you're referring to, where do they send to? Something like my "Mix Bus Folder", or directly to "Reaper Master Out"?

If it's the latter, can you try adding a new "Mix Bus Folder", moving all FX from "Reaper Master Out", and turning off PDC on "Mix Bus Folder"?

[dyross]

Originally Posted by mks

My “top levels” feed Reapers master out. Typically with processing there. As well as monitoring effects too. Though this bug is reproducible without either of those in play at all. I’ll test nesting them into a master bus folder to be thorough, but it seems like it’s a compounding issue regardless of how many levels deep. As soon as you have various amounts and depths of PDC, Reaper has increasing difficulty in assigning that processing without audible or gui glitching.

I'm hoping it's as easy for you as adding a master folder / send, but I doubt it. But worth checking just in case!

[mks]

Unfortunately not. But at least it follows consistently and hope that helps get this looked at. Getting tricky to finish complex mixes here recently

Originally Posted by dyross

I'm hoping it's as easy for you as adding a master folder / send, but I doubt it. But worth checking just in case!

[Ollie]

Originally Posted by mks

I've setup a quick testing session here and have done the following:

Thank you for setting this up! This (project as simple as possible without 3rd-party plug-ins) is really the best start to get to the bottom of this. Would you mind jotting down some steps what to do with the project? ELI5 what should happen then? (I'm asking because I can run it, open things, seek.. without any observable malfunction?).

What are your system specs, sample rate and buffer settings?

[norbury brook]

hello all. I've downloaded this session in an attempt to help out here if I can.


What are we supposed to be seeing when running this?

the session runs fine for me, smooth as silk, nice smooth GUI, soloing and muting tracks is instant , no crackles or anything.

what am I looking for?

testing on a 12900 laptop with Antelope Zen Q interface @256 sample buffer.

I get a slight crackle when returning to the loop start if I hit stop otherwise it runs perfectly here.



M

[0xRAIN]

I wanted to chime in on this thread because I run into the same sorts of behavior when I'm working on large projects. Like pretty much everyone else here I have a routing setup that involves both nested folders, sends/receives, etc. I made a very simple diagram of the high level routing: https://i.imgur.com/KMHTfbS.png

I also use outboard gear while mixing, sometimes on individual tracks but always on the Instrumental and Mix busses like in my diagram above. Those tracks usually have some additional FX on them, but the ReaInsert instances tend to drive PDC up the highest, which is not unexpected. Coupled with all the side chaining/folders/nested folders going on it becomes complex quickly. I'm working on a ~120 track project right now using that routing. Up until last night things were going really well but performance started getting progressively worse and worse. Longer to start playback, longer to stop, sometimes things would just stutter and playback at 1/4 speed while others were at normal speed, and of course tons of crackles and all the usual annoyances.

This morning I downloaded a portable Reaper install and loaded the project up and it played back completely fine. Thinking maybe I had messed around with the wrong config options I loaded my "normal" install and things played completely fine. Toggling Anticipative FX per track (my ReaInsert tracks) made no noticeable difference. Playback was immediate and I can jump to any part of the song almost immediately and it doesn't stutter or drop out. Muting tracks also doesn't cause Reaper to trip over itself for 15+ seconds like it did last night or in previous projects.

I honestly think one or more plugins are behaving poorly, and maybe it is something specific in Reaper that isn't being handled appropriately. I also noticed the PDC values reported in Track Manager last night were well over 10,000+ on the tracks with ReaInsert (and other plugins). Today loading the project up without changing anything they're reporting ~8000 and ~6000 and things feel "normal". To be clear, my system is definitely being stressed with this config but it can play back/render in real time without glitching out just fine by and large. It also shouldn't take what feels like 30 seconds to open a MIDI editor, click an event, and hear the sound 60 seconds later, which is what was happening last night.

My plan is to keep a better eye on the PDC values in track manager and if they start to significantly change or go up I'll look at recent plugins I've added and what they're doing. The more I think about this as I write this out I'm almost positive this is related to plugins misbehaving/not reporting the right values to Reaper. I can't fathom why my projects would play correctly on a fresh startup vs. slowly grinding down to misery over the course of a few hours of working. Some plugin was re-instanced correctly when I start the project up is the best guess I can make.

[dug dog]

Originally Posted by 0xRAIN

I can't fathom why my projects would play correctly on a fresh startup vs. slowly grinding down to misery over the course of a few hours of working.

I've noticed the same behavior on a regular basis and, in my case, sometimes I've done only 10 minutes, or so, of tweaking before the project starts to glitch out and I have to close the project and re-open.

I should point out that I'm on a relatively old laptop and my projects are considerably smaller than yours, but I have similar routing set-ups with nested folders and sends between folders. A fair number of high PDC plug-ins as well, but I guess that goes without saying.

[mks]

Thanks so much for looking. The simulated session is a tricky one since the problem relies on a number of factors including the DSP load. Which is where my theory on threading behavior for pdc compounded tracks comes into play. On more powerful systems this test may require a high load. This test tries its best to push things using (the typically low cpu load) stock plugins, but turning on over-sampling on a few to increase that.

To help answer your questions:

The behaviours to observe would include:
- sluggish muting and unmuting
- crackling on play and stop
- other stuttering behaviour

The key things to adjust to stress more powerful systems to a reasonable level would be:
- increasing the thread behaviour (not realistic, but will hopefully get you there)
- playing with buffer sizes for the same reason
- enabling over sampling on a few more reafir instances or duplicating any combination of tracks

Again, this test is a little more tricky to do using stock plugins since they’re all pretty efficient but it can be done. In typical use with all sorts of DSP effects, this problem comes up pretty quickly. I just made this to show that it wasn’t tied to third party plugins only. I’ll do my best to make another test session that requires less messing about.

Originally Posted by norbury brook

hello all. I've downloaded this session in an attempt to help out here if I can.


What are we supposed to be seeing when running this?

the session runs fine for me, smooth as silk, nice smooth GUI, soloing and muting tracks is instant , no crackles or anything.

what am I looking for?

testing on a 12900 laptop with Antelope Zen Q interface @256 sample buffer.

I get a slight crackle when returning to the loop start if I hit stop otherwise it runs perfectly here.



M

[mks]

Really interesting observations on the PDC calculations changing when you reopened the plug-in. Seems to implicate that something is amiss with calculations there.

I just wanted to point out that I’ve been able to recreate this problem with just stock plugins. So the third-party factor does not seem to be key. Though it is more realistic in the way the way the request/require DSP which is partially a factor.

Though your other observations are really useful too. It’s really hard to track down. Have you tried adjusting the thread behaviour thing? I’d love to hear how much that impacts things for you.

Originally Posted by 0xRAIN

I wanted to chime in on this thread because I run into the same sorts of behavior when I'm working on large projects.

[dug dog]

Originally Posted by norbury brook

What are we supposed to be seeing when running this?

The test project stutters right away on my old lappie. Intel i7 2720 QM running Windows 7 X64 and the onboard sound card. Reaper and Windows both show CPU use in the 15-20 percent range.

[dug dog]

Originally Posted by mks

Really interesting observations on the PDC calculations changing when you reopened the plug-in.

I hadn't been paying regular attention to this factor but I definitely observed this behavior on one occasion.

[norbury brook]

Ok, reloaded this again this morning and tried again at 64 sample buffer.

Everything still running smoothly with the occasional crackle.

Tried @32 sample buffer and it was just too low for this project, general ASIO overloading crackles. The GUI and muting /soloing were still smooth and instant though.

I tried a different mix project @32 sample buffer and had similar issues though so on my machine large projects needs @64 and above really.

Not sure if that was helpful? let me know if i can be more specific in helping out here.


M

[mks]

Thanks for loading this!! Most important is the thread behaviour preference. Where did you have that set? That and combing it with higher buffer settings like 512 or 1024 would more specifically test this specific behaviour.

Originally Posted by norbury brook

Ok, reloaded this again this morning and tried again at 64 sample buffer.

[norbury brook]

Originally Posted by mks

Thanks for loading this!! Most important is the thread behaviour preference. Where did you have that set? That and combing it with higher buffer settings like 512 or 1024 would more specifically test this specific behaviour.

ah didn't check, whatever is default.


At higher buffer? well at 256 the project ran without a single glitch, smooth as silk so I imagine at higher it will be the same. I thought the point was to stress the system and the only was was to lower buffers.


shall I try again @512/1024 and give me a setting for the thread behaviour

M

[mks]

No worries and I appreciate you trying. Sorry my post wasn’t more specific. We’re trying to stress the threading performance specifically. So setting that to “very aggressive” is KEY to simulating this (side note: in real world use, this happens at default settings too…just hard to make a simple real world load scenario with just stock plugins). Combining that with larger buffer chunks would potentially make the issue more apparent which is why I’m suggesting that as well.

To clarify: we’re specifically not testing CPU load alone since what makes this buggy is that it’s not just a predictable system load limitation. It’s something that occurs with even light to moderate CPU load. We’re trying to give the hardware lots of consecutive chunks of things to do with various levels of required timing compensation to see where it trips on itself

Originally Posted by norbury brook

ah didn't check, whatever is default.

[norbury brook]

Originally Posted by mks

No worries and I appreciate you trying. Sorry my post wasn’t more specific. We’re trying to stress the threading performance specifically. So setting that to “very aggressive” is KEY to simulating this (side note: in real world use, this happens at default settings too…just hard to make a simple real world load scenario with just stock plugins). Combining that with larger buffer chunks would potentially make the issue more apparent which is why I’m suggesting that as well.

To clarify: we’re specifically not testing CPU load alone since what makes this buggy is that it’s not just a predictable system load limitation. It’s something that occurs with even light to moderate CPU load. We’re trying to give the hardware lots of consecutive chunks of things to do with various levels of required timing compensation to see where it trips on itself

Ok set to very aggressive and 1024.


Everything still smooth , you notice a delay now with soloing due to the buffer size, it's consistent and glitch free though.

The only glitch is when hitting stop. I recognise this sound as it happens with Acustica Silver if I@m using it. It's basically the clearing of the buffers and the larger they are the more its noticeable. Hitting Pause is silent.


So it's running fine here on my laptop albeit with the inevitable delay and audio engine clearing it's buffers which it does on any project using large buffers I've found.


M

[ferropop]

Originally Posted by norbury brook

Ok set to very aggressive and 1024.


Everything still smooth , you notice a delay now with soloing due to the buffer size, it's consistent and glitch free though.

The only glitch is when hitting stop. I recognise this sound as it happens with Acustica Silver if I@m using it. It's basically the clearing of the buffers and the larger they are the more its noticeable. Hitting Pause is silent.


So it's running fine here on my laptop albeit with the inevitable delay and audio engine clearing it's buffers which it does on any project using large buffers I've found.


M

If you're able to throw Soothe2 into the mix somehow (they have a trial I believe), or Gullfoss...

[ScuzzyEye]

Originally Posted by norbury brook

The only glitch is when hitting stop. I recognise this sound as it happens with Acustica Silver if I@m using it. It's basically the clearing of the buffers and the larger they are the more its noticeable. Hitting Pause is silent.

Curious, while you were changing buffer settings and other things while troubleshooting, did you try the preference: Audio, Buffering, Behavior? I had a lot of similar problems to what you described, when it was on Auto. I changed it to "3 - Medium", and it solved everything. Including the audio continuing to run after I've hit stop. Though in that case, the GUI was also unresponsive until the audio finished playing what was in the buffers. That was the real core of what I was trying to solve, the GUI seeming to get higher priority than the audio engine, and taking a lot of resources away from RT playback.