Bad DSP performance in Reason

Hi everyone,

did anyone else experience a real bad DSP performance when running a VST in Reason?

My synth plugin requires about twice the amount of CPU when run in Reason compared to other DAWs. In other words, I can only play half the number of voices before droputs occur. Similar performance issues can be observed with plugins from other vendors. Buffer settings and sample rate are identical in all DAWs I have tested…

Any ideas why Reason performs so bad and what I could do to optimise my plugin for Reason?


The most obvious thing to check would be, if the DAWs you are comparing run on the same sample rate and more important the same block size?
Don’t look only on the values you set in your system but rather what your plugin receives in the processBlock calls (even the number from prepareToPlay can differ, since that is only a maximum number to reserve…)

Hope that gives you more insight…

1 Like

Thanks, Daniel! Indeed, the debugging in processBlock() reveals that the effective buffer size in Reason is one fourth of what is set in the settings dialogue and only 64 samples instead of expected 256.

That somehow explains why I have a higher CPU load. However I wonder if the overhead of each processBlock() call is responsible for a 50% performance drop when going from 256 to 64 samples block size…

Anyway, quite annoying that Reason uses a considerably lower buffer size to feed the VST plugins :confused: haven’t found a setting in the preferences dialog to change this behaviour…

Since it changes the expected buffer size going into the plugins, is it perhaps possible it also changes the sample rate to be higher than expected? Also, does Reason run the 3rd party VST plugins in a separate process?

Ok, the increased load of the plugin thread is reproduceable in other DAWs if I also go down to 64 samples. However, that is only part of the story and does not explain the 50% performance drop…

The profiler shows that most ressources are consumed by 2 other internal Reason threads which take the same amount of CPU time as my plugin thread.

Xenakios: Sample rate is the same and it seems plugins are in the same process.

The overhead of each graph rendering call is very significant, and using a quarter of the block size obviously increases the overhead 4x. It always amazes me that anything works at all at 64 samples!

Does the behavior seem more reasonable (cough) if you have multiple instances of your plugin in the Reason project, or other plugins/Reason devices in it? Maybe there’s just some generic overhead in Reason for just running the audio at all.

Does Reason hammer your plugin with parameter changes that may not even be needed? (I recently saw that kind of behavior in Cockos Reaper with my plugin.)

1 Like

No, in the profiler it appears there are 3 threads, one from my plugin which shows a load similar as in other DAWs, and 2 other threads which have about the same load. This is reproduceable with plugins from other vendors, too.

Does it do something crazy like load and process the same plugin multiple times even if just one instance is expected?

Less crazy, does your plugin have some expectation on the memory alignment of the audio buffers passed from the host? Maybe the Reason VST hosting doesn’t allocate aligned buffers.

No, it’s three different threads. At least only one of them has my debug symbols and is from the plugin.