v6.x Reaper 3-second freeze on PLAYBACK past about 7000 envelopes

[airon]

This bug appears to relate to a specific number of activated and armed plugin parameters. It may also have something to do with the over 8500 media items in the session.

This limits Reaper to be usable for mixing only to a certain amount of plugin parameters. It does however look like something is going on as the time Reaper takes to repare playback to commenct all of a sudden grows abnormally fast.


The session and my Reaper.ini file has been sent to support@cockos.com with the subject line (almost)identical to this threads title. Hardware is a 16-core/32-thread CPU, 64 GB Ram with all audio being played from an NVME SSD. There is rarely more than two or three audio files playing at the same time. The settings are pretty much at default, though the automation is modified.

Session details:

• 8529 media items (many with multiple takes) scattered over 15+ hours of a 23.976 fps timeline.
• About 9*22 minutes of material mixed, i.e. has automation written to it. (added from 2nd post)
• 1 video track (no audio)
• 7 tracks with no plugins, just audio and no sends
• 7661 plugin parameter envelopes(a rough count)
• 56 tracks with 5 plugins(mono), 126 automated parameters, scattered bits of audio and 8 fully automated sends(volume,pan,mute)
• 2 tracks with 3 plugins(stereo), 58 automated parameters, scattered bits of audio and 8 fully automated sends(volume,pan,mute)
• 8 tracks with 2-3 plugins(stereo), and over 58 receives
• Two parent tracks collecting all the above tracks

The performance meter shows no abnormal CPU use on any tracks during playback.

This only occurs on this large session specifically. I have an ongoing session with far less tracks, plugins and media items.


The Threshold (for reproduction)

• Once the number of plugin parameters is around 7000+ and a certain amount of envelope data has accumulated, because this did NOT happen when the session only had 160 minutes or so mixed.
  
  In the session that is bypassing all plugins in a track from about "Crowd 7" downwards.
  
  
• Around that threshold the freeze/delay rapidly shows up, rapidly growing with activating just a few more plugins. Then the effects below become pronounced and the session becomes a slog to work in.

The Bug/Performance Issue
3+ second freeze under the following circumstances

• Execute PLAY after a having relocated the edit cursor/playhead in STOP mode.
• Stopping playback and relocating the edit cursor/playhead right away.
• Activate a track SOLO after having relocated the edit cursor/playhead in STOP mode.
• Unsoloing all tracks after having relocated the edit cursor/playhead in STOP mode.
• Calling an external editor on a copy of a selected item.

The Bug/Performance issue does NOT happen when

• relocating the playhead during ongoing playback by for example clicking in the time ruler(seeking with time ruler enabled)
• Pausing playback with the "Play/Pause" action and then resuming playback with the same action
• due to video use. Removing the video showed no change
• due to a specific version of Reaper. I tested versions back to 6.28, so the change wasn't recent, but may be a systemic problem.

Additional details

The Task Manager shows a CPU use of 98-100% during those three seconds. That's 32 fully loaded cores.

Plugins are not affected. Fabfilter Pro-Q3 happily displayed metering and spectral analysis during Reapers freeze. It runs that stuff off the GPU.

The session consists of

• 60 dialogue tracks, each running five almost fully automated plugins and eight automated stereo sends.
• Two parent tracks for the dialogue and effect child tracks.
• Two playout tracks and various utility tracks(video,etc.)

CPU use graph from several playback starts. The spikes are the freezes. The playback CPU use is around 30% at most.

[airon]

One detail I should mention is that this session was fine up until I had about 9 episodes mixed, which are about 22 minutes each.

So the amount of envelope data may be playing a role as well.

-edit-
Added to the first post.

[airon]

One interesting statistic.

Accoding to a Notepad++ regex search of the session

PT.*$

there are 599776 envelope points in that session, so far. That includes volume, pan, send volume, send mute and plugin parameters.

I started with 9086, which was a clean writing pass for all automated parameters on all tracks, which were only template tracks, and no media items.

[tonalstates]

I've had similar issues on a 20min foley/sound design project I'm currently working on. Everything is fine, until it isn't out of nowhere.

[airon]

It looks like something in Reaper is overflowing or some inefficiency that had no impact at lower counts of plugins, active envelopes and envelope points.

Now it's showing up by freezing everything for several seconds before playback can commence, or a damn solo (in STOP mode no less) can take effect.

Something is messing up here and we're at that edge case.

I hope the devs have an hour or two to figure this out. My sessions are probably not getting smaller, though I'll need to split this one up a bit.

And that's another thing.

Having several heavy hitter sessions loaded doesn't slow down the individual sessions either. I have a six episode 40 tracks of 5 plugins with 120+ envelopes plus effect sends, AND that heavy hitting 15 hour session of 0.75 million envelope points loaded. Makes no difference to the smaller session.


Note to devs.
If handling these larger loads of envelopes, envelopes point and plugins can be solved by using an extra gigabyte of memory, do it! That's what I have all that RAM for. Mostly power users will require such expansive automation and the high track&plugin counts.

[RobinGShore]

I've never tried to quantify it as thoroughly as Airon has here, but I've also had similar problems sometimes on big projects with tons of plugin and send automation. Delayed playback starts, and slow solo and mute activation if the transport is stopped. Also Reaper will randomly hang for a few moments sometime if I scroll the arrange or zoom in/out. None of this has ever gotten so bad for me as to make things unworkable, but it would certainly be nice if this didn't happen.

Another thing I've noticed with big projects that may or may not be related: In certain projects reaper will hang for a long time when opening the media bay for the first time after loading the project. I've had projects where Reaper froze for over 5 minutes when I opened the media bay. After the media bays been opened once everything is fine and it can be closed and opened again without any delay until Reaper the project is closed. Same thing happens with saving on these projects. The first save after loading these projects will make reaper hang for a long time, but after that all subsequent saving happens quickly.

[Justin]

Originally Posted by RobinGShore

Another thing I've noticed with big projects that may or may not be related: In certain projects reaper will hang for a long time when opening the media bay for the first time after loading the project. I've had projects where Reaper froze for over 5 minutes when I opened the media bay. After the media bays been opened once everything is fine and it can be closed and opened again without any delay until Reaper the project is closed. Same thing happens with saving on these projects. The first save after loading these projects will make reaper hang for a long time, but after that all subsequent saving happens quickly.

Can you send a copy of one of these .rpp files to support at cockos? thanks!

[airon]

I could attempt to replicate this with Cockos plugins, including the 1500 or so samples of PDC on every dialogue track. Achievable with Reacomp and pre-comp.

Reverbs and Delays are zero latency except for Stratus which has 32 samples. All low cpu. Not a lot of envelope points. Low level noise as files. Write some values for all plugin parameters, duplicate tracks, scatter items evenly with a item position randomizer, then duplicate sequence until the desired number of envelope points is achieved. A shame there‘s no project report on that data, but Notepad++ can reload and is fast on the Regex search.

If you don‘t do it, I‘ll give it a whirl on Monday at the latest.

Iirc the pdc on the dialogue tracks was 1536 samples for some reason. 256 sample ASIO buffer.

[RobinGShore]

Originally Posted by Justin

Can you send a copy of one of these .rpp files to support at cockos? thanks!

I just checked and the freezing doesn't happen when the media is offline. These projects all have many gigs worth of media so uploading it all would be kind of a pain. Is it still useful to send you a project if you won't have any of the media?

[airon]

That sucks. My project is around 20 GB.

Maybe test what happens if you use a simple piece of noise for all media items. I‘ll give that a try when I‘m back in the studio.

[airon]

So far it seems to require using the plugins the way I do.

The send effects don't make much of an impact, but the send automation might.

I replaced every source of every media item with the same piece of noise and got some of that delay freeze for all the listed actions.

Justin, if you had those plugins, even as an NFR, this could probably be replicated. If you delete the Waves Sibilance plugin, just duplicated a couple of tracks. That's one way.

I tried to recreate this with Cockos plugins, running a ReaComp with 30+ milliseconds of precomp and a second with half a second of precomp. The rest of all parameters are automated. A couple of dozen items on the tracks, but only identical envelope points at the edge of each. In the proper session there will be a clean pass across the entire session for a character or its items if they share a track with other characters, and then adjustments here and there for the situation.

So far no luck recreating that with random item placement.

I pushed the number of envelope point to over 14 million across 100+ tracks that housed four plugins each, fully automated. It got a slight bit sluggish sometimes, but nothing close to what I experience in my session. The envelope count only got to 7740 too. The problem session actually has 9286(regex search for "PARMENV.*$").So no replication so far.

I can send you the session where all media is replaced with a noise file, though you can do that yourself in 10 seconds.


I got the session to work well again just by throwing out the barely automated and used pre-comp eq on most tracks. That plugin has no latency. And it only reduced the PARAMENV count from 9286 to 8697




Maybe it has something to do with the number of envelopes and how each plugin responds to setting parameter values being set. It could be something weird in Fabfilter plugins.

So it could be the response time of the initial setup. When all the listed actions are triggered, something takes a lot of time and is running on lots of threads before the actual playback happens.

[airon]

I've got something widdled down to just Fabfilter Pro-Q3 and Fabfilter Pro-C2, the eq and comp. This might work fine with the trial versions of the plugins or an NFR provided by Fabfilter.

In this case I copied the track-fx including automation from the track "Hinata" of the original session, pasted that in to a track with random items of noise.

The deessers got deleted and replaced with ReaComp(fully automated with precomp). That left just those two Fabfilter plugins.

I replicated the track to get 100 of them, randomized the item placement within 30 seconds for all but the first track(SWS Randomize item position), and got the freeze here and there.

I've sent the session (5 MB RAR file) to support at cockos dot com.

[BengtS]

I have also the same issue. When the project is bigger than a certain threshold, it turns very sluggish, just like OP writes. Also my CPU load is very low during playback. I am using the v6.33 on Windows.

But: When I stop, one core is running at 100% and the rest are not. To get this effect, I have set the "Do not allow the OS to relocate worker threads to different CPUs" in the preferences.

I have the feeling that the size of the VST parameters is playing a role here. The project gets much more responsive, if I delete those VSTs that use a lot of space to store the status.

On the other hand, it could also be the total size of the project. If the project is 500k it is much more sluggish than if it is 350k.

If it is less than 100k, everything is without any delay.

Automation points do not seem to be important for the issue I am seeing, except possibly for increasing the size of the project.

Perhaps there is some sorting being done when pressing stop or solo or any of the other commands that cause these delays?

[BengtS]

It seems that the new version 6.34 solves the issues I have reported here.

Large projects (100+ Tracks with many plugins) are now much more responsive and playback starts and stops much quicker.

Very happy!

[airon]

I'll give this a try. Thanks for posting about this.

[airon]

I tested v6.34 with the large session I sent in, and so far it all works fine.

I jumped around in the session, playing in dozens of spots that would often produce the three second freeze. So far it's working better than before.

I'll give this another test from time to time and report back if anything shows up again. Of course I've split the 28 episode session up I had before, which is fine and not a big deal. The problem is somewhat unlikely to show up again right. I'll keep an eye out though.

Thank you for whatever fixes or changes you may have made gentlemen. So far it's looking good on the first try.

[BengtS]

I checked today with a much bigger project of some 250 tracks.

While being much faster than before, it was still rather sluggish.

So, whatever was changed, it did help a lot, but there is still some more to be done.