"Process on stop" causes CPU spike on relocate

[mks]

Does anyone knows what Reaper does upon moving the playhead with respect to processing on the Master bus (or anything requiring RT processing)? This happens even if the locate isn't moved and just clicked on again. It seems to be related to "allow processing when stopped". Disabling this makes it go away, but is obviously impossible to use in that state for most things.

There seems to be a huge RT CPU spike that happens when doing this. Made worse by the fact that if you're trying to work fast and hitting play right away, it can get into a state where it takes several seconds to recover from whatever it's doing before actually engaging play.

I recently posted what seemed like a similar behaviour. But that was related to a plugin bug with respect to adaptive processing. Though this somehow feels like it might be related.

For instance, in one session: I have RT useage hovering around %17. But relocating (while stopped) makes it jump to %50. God forbid I click two or three times in a row where it compounds and brings the whole thing down.

It feels like there is some buffer clearing/reloading or something happening to allow for the continuation of processing due "allow processing on stop". The fact that it compounds and happens when simply relocating is a little strange beyond the fact that the spike happens at all.

Any thoughts on places to look to try to optimize this? Other than disabling that functionality.

[schwa]

Assuming you mean "run FX when stopped", my guess is that you have some plugins with significant latency in the project. When latency/PDC exists, REAPER buffers track output as needed to ensure that playback is synchronized on all tracks.

For example if you have no plugin latency on track A, 10ms of plugin latency on track B, and 100ms of plugin latency on track C, then REAPER always has to hold 100ms of track A and 90ms of track B output in a buffer.

When the playback position changes, REAPER has to discard all of the buffered output and start over. So before any signal can actually be played back, 100ms of track A output and 90ms of track B output have to be processed. If the audio device latency (the block size) is say 5ms, that means all at once REAPER has to effectively do 20+ times more processing than it normally does in a single buffer block. If that processing can't be completed in time, playback has to wait.

[mks]

Thanks so much for responding Schwa. And apologies for my mistake, yes, I meant to write "run FX when stopped".

That certainly makes a lot of sense and assumed it has something to do with delay compensation buffering. I guess where I was confused was regarding the different way this is handled when "run FX when stopped" is enabled vs when it's disabled. Didn't quite think it through that the same type of delay compensation buffering would be handled differently in each configuration.

To help me understand further, hope you don't mind a few more questions/clarifications:
- when the "run FX when stopped" function is disabled, the buffer "load-in" does NOT occur until playback is engaged?
- as compared to when it is enabled, where it occurs at all times? Hence the flushing and reloading on relocating?
- this could be just due to imprecise CPU load metering but: I'd imagine the buffer "load-in" CPU load would be the same in either case. Unfortunately it seems to be a significantly higher peak when enabled and nearly imperceptible when disabled and entering playback. To the point of sometimes causing the Reaper to become unresponsive.
- Similarly, when enabled: relocating numerous while stopped can really cause the load to climb. But when doing so while playing the load stays imperceptible again. This one is curious. I thought this might have something to with "flush FX when stopped", but that made little difference (rather got worse as I would expect with it disabled).
- the compounding nature of this also feels a little strange. In that numerous relocates when stopped can sometimes add up to a system overload, but doing so while playing does not (whether enabled or disabled).

I'm not sure if something is amiss, and probably not. But thought I'd bring it up to understand the inconsistencies in system load for what would appear to a very similar buffer exchange or load scenario.

[Justin]

Ah there might be a simple fix for this issue, coming to the next +dev builds, will post in here again when it's available to test!

[Justin]

The latest +dev builds should improve this, please see the pre-release forum!

[mks]

Amazing Justin! I'll have a look shortly! Reaper has been such an incredibly efficient tool and has run huge sessions...except for this one area that seems to bring it down really quickly despite all the apparent processing overhead.

[mks]

Oh wow. This is a huge performance/usability improvement. I just tested this on some of the more troublesome mix sessions I've been trying to finish and I don't see any of these behaviors at all! Thank you!

I will continue discussion in the appropriate forum, but can't wait for this to become a release. Not sure which version or which specific addendum this is tied to, but will ask over there.

Feels like I have a whole new workstation

[kytdkut]

yes yes yes yes yes thanks!!!