Go Back   Cockos Incorporated Forums > REAPER Forums > REAPER Bug Reports

Reply
 
Thread Tools Display Modes
Old 11-18-2012, 05:17 AM   #1
tumult
Human being with feelings
 
Join Date: Feb 2009
Posts: 52
Default Unexpectedly bad performance with PDC on receiving tracks

I'm not sure if this is a known problem, and isolated problem with just my own setup, a design decision, or something that has just not come up before.

When you have some tracks with effects that use a lot of CPU, and they are sending to a track which is using PDC, there can be unexpectedly bad performance. There can be issues normally associated with CPU exhaustion (buffer overruns, playback stuttering, etc.) even though it seems as if the CPU should not be exhausted.

Let's try an example.

First of all, here are my playback device settings:



I'm going to create a project with some tracks and lots of plugins on them, causing some CPU load. I will insert a bunch of the Native Instruments VC76 plugin. I chose this plugin because it uses a decent amount of CPU, but does not use plugin delay compensation. However, any plugin that uses CPU will be fine for replicating this problem.



I have to insert quite a lot of them to cause any noticeable load on my CPU.

Now I'll make 4 of these tracks, and play some audio from a clip through them. These 4 tracks will send to a track that has no plugins on it.



Other than sounding like it's been pummeled with a jackhammer, this plays back fine. No breakups or overruns, no playback stuttering.

Take a look at this simple JS effect I've made.



All it does is add PDC to the track it's inserted on. Let's insert it on one of the tracks.



This still plays back fine. No problems.

Alright, let's try inserting the PDC plugin on the other tracks.



Yet again, playback is still fine.

Now, let's remove the PDC plugin from the tracks with effects, and put one on the receiving track that's being sent to.



Result: constant buffer overruns and terrible playback. It's impossible to work like this.

Why is this happening? My guess is that it has something to do with anticipative FX buffering and multicore usage. I don't know what REAPER is doing internally, so I can't say for sure. But it means that projects which have CPU-expensive tracks sending to other tracks which have PDC become impossible to work with.

Is there anything that can be done about this? Is it a performance flaw that can be improved, or a deliberate decision?
tumult is offline   Reply With Quote
Old 11-18-2012, 07:52 AM   #2
reapercurious
Human being with feelings
 
reapercurious's Avatar
 
Join Date: Jul 2007
Posts: 1,623
Default

im pretty sure pdc is evil?
reapercurious is offline   Reply With Quote
Old 11-18-2012, 02:10 PM   #3
Justin
Administrator
 
Justin's Avatar
 
Join Date: Jan 2005
Location: NYC
Posts: 10,320
Default

If you bump up the anticipative FX multiprocessing setting to its default (200ms), does that help?
Justin is online now   Reply With Quote
Old 11-18-2012, 06:46 PM   #4
tumult
Human being with feelings
 
Join Date: Feb 2009
Posts: 52
Default

I'll play around with the buffer size when I'm back at my studio tonight, and post the results.
tumult is offline   Reply With Quote
Old 11-19-2012, 02:40 AM   #5
tumult
Human being with feelings
 
Join Date: Feb 2009
Posts: 52
Default

Ok, I've played around with it for a bit and observed its behavior.


With Anticipative FX Render-ahead set at 1000ms, 992ms of PDC on the receiving track is fine, but 993ms of PDC causes overruns/breakups.


With Render-ahead set at 200ms, 191ms of PDC is fine, but 192ms causes breakups.


With Render-ahead set at 25ms, 17ms of PDC is fine, but 18ms causes breakups.

This is with my audio device set the same as the earlier post (256 samples @ 44khz). The breakups begin exactly after the duration of the amount of Render-ahead. So, if I have the Render-ahead set at 1000ms and PDC on the receiving track set at or above 993ms, there will be exactly 1 second of pristine audio before playback becomes completely broken up. If I have it at 992ms or under, it will be perfectly fine, not even an occasional pop or click.
tumult is offline   Reply With Quote
Old 11-22-2012, 12:09 AM   #6
tumult
Human being with feelings
 
Join Date: Feb 2009
Posts: 52
Default

Any updates? Should I post this in the bug tracker?

Once I start using sends (or mix buses/folders) in a project, this problem can become pretty pronounced. Of course, I can keep increasing the anticipative FX play-ahead, but once it gets above 500ms REAPER becomes very unresponsive to parameter and fader changes, and pause/playback/seek have huge latency. It's difficult to work under those conditions.

Certain plugins I'm using now use a large amount of PDC, and 5000+ samples of PDC can be pretty common. I imagine other people are hitting this issue as well.
tumult is offline   Reply With Quote
Old 11-22-2012, 02:50 PM   #7
Justin
Administrator
 
Justin's Avatar
 
Join Date: Jan 2005
Location: NYC
Posts: 10,320
Default

I think I have an understanding for why this is, we will look at improving the performance in these scenarios at some point.
Justin is online now   Reply With Quote
Old 11-22-2012, 06:11 PM   #8
tumult
Human being with feelings
 
Join Date: Feb 2009
Posts: 52
Default

Awesome, thanks!
tumult is offline   Reply With Quote
Old 11-27-2012, 05:37 AM   #9
Dstruct
Human being with feelings
 
Dstruct's Avatar
 
Join Date: Jul 2006
Location: Dresden, Germany
Posts: 12,004
Default

Thanks for looking into it!
Dstruct is offline   Reply With Quote
Old 11-27-2012, 06:48 PM   #10
Justin
Administrator
 
Justin's Avatar
 
Join Date: Jan 2005
Location: NYC
Posts: 10,320
Default

Some of the 4.32 builds should improve this, if you want to visit the pre-release forum.
Justin is online now   Reply With Quote
Old 12-02-2012, 08:17 AM   #11
tumult
Human being with feelings
 
Join Date: Feb 2009
Posts: 52
Default

Great, thanks. I'm out of the country right now, but I'll check it out when I'm back in the studio next week.
tumult is offline   Reply With Quote
Old 12-26-2012, 11:12 PM   #12
tumult
Human being with feelings
 
Join Date: Feb 2009
Posts: 52
Default

Been using it for a couple of weeks. It seems quite a lot better! Awesome, thanks. I'll let you guys know if any more pathological cases come up.
tumult is offline   Reply With Quote
Old 05-24-2013, 11:54 AM   #13
tumult
Human being with feelings
 
Join Date: Feb 2009
Posts: 52
Default

Hi guys. Unfortunately, there seems to have been a partial regression of this fix.

The regression:

While in sustained playback, performance and audio is fine. However, there are GUI lockups and audio dropouts when any of the following actions take place:
  • Muting or unmuting a track with a send to a track with PDC
  • Muting or unmuting a track with PDC and receives from other tracks
  • Soloing or unsoloing a track
  • Adding, removing, bypassing, or unbypassing an FX on a track with sends to a track with PDC, or on a track with PDC and receives from other tracks.
  • Starting playback
  • Pausing playback
  • Probably more
Summarized changes in behavior across REAPER versions:
  • 4.32-dev-pre2 and earlier: Constant dropouts with large PDC on receiving tracks.
  • 4.32-dev-pre3: No dropouts during playback or when actions are taken with large PDC on receiving tracks. (Best behavior)
  • 4.32rc1: Constant dropouts with large PDC on receiving tracks. (Old, bad behavior)
  • 4.33pre1: No dropouts during playback, but dropouts when actions are taken with large PDC on receiving tracks. (New, partially bad behavior)
Note that this means 4.32 final included the original bad behavior.
The release notes for 4.33 include the following:
Quote:
+ Multiprocessing: improved anticipative FX with sends to tracks that use PDC [t=113560]
This leads me to believe that the original fix may have been removed intentionally for the release of 4.32, starting with 4.32rc1, with plans to re-include the fix (perhaps with changes) in 4.33.

Additionally, I tested the following major releases by hand:
  • 4.33
  • 4.40
  • 4.401
  • 4.402
  • 4.5rc1
and they all exhibit the new, partially bad behavior.

Note that when attempting to reproduce this problem that the 'only_pdc' example JS from earlier in this thread will not cause many audible audio dropouts. However, you will still be able to see the GUI lock up and you will hear a delayed response when muting or unmuting tracks, bypassing FX, etc. To more easily reproduce the audio dropouts, try using a VST plugin that is actually processing audio.

Let me know if you have any questions, or if there are any ways I can help out. I'm sorry I didn't report it earlier; I was in the middle of a large project and was not upgrading any of my software at the time (I had been using 4.32pre5).

Last edited by tumult; 05-24-2013 at 02:47 PM.
tumult is offline   Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -7. The time now is 08:13 PM.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2017, vBulletin Solutions Inc.