Using the D16group LuSH-101 VST in Reason 10, things seem backwards in regards to the state of the "multicore" mode in *both* Reason and in LuSH-101's internal Options page and the actual performance of the synth / CPU usage.
- if both Reason and LuSH-101 have their Multicore option ON, the synth consumes massive CPU and crackles / pops with pretty much any playing of keys
- if I turn Multicore OFF for *either* Reason's Preferences or LuSH-101's options page, the CPU drops and crackling / pops go away, everything behaves as you'd want it.
So, my solution is to leave it off only on the LuSH-101 interface, so that Reason itself can still use Multicore, but I'm just confused why I'm having to do this at all, shouldn't Multicore be helping the CPU usage, not hurting?
When I use LuSH-101 in Ableton or Studio One, this whole scenario is reversed: I must turn on LuSH-101's MultiCore support, or I get tons of crackling / pops, etc.
Are there other VST synths where this also happens in Reason? I'm assuming yes, because I've only tried a few VSTs so far...
my system is a 2016 iMac with 16gig RAM, 4Ghz Intel Core i7, running El Capitan
- m.arthur
Far lower CPU usage when LuSH-101's "multi core" mode is OFF...why?
- esselfortium
- Posts: 1456
- Joined: 15 Jan 2015
- Contact:
From what I understand, this is typical and expected behavior. You want to have either your host managing multi-core performance, or your instruments managing multi-core performance themselves. Having both of them enabled means they'll be stepping on each others' toes.
Sarah Mancuso
My music: Future Human
My music: Future Human
What's confusing about that, if you're right, is that this is not true for any other DAW I own (Ableton, Studio One). In those, I have to enable LuSH-101's mutli core mode regardless of the host setting, or I'll get the crackling, etc....esselfortium wrote: ↑28 Oct 2017From what I understand, this is typical and expected behavior. You want to have either your host managing multi-core performance, or your instruments managing multi-core performance themselves. Having both of them enabled means they'll be stepping on each others' toes.
It might again be connected to the fact that Reason runs all plugins at a constant 64 samples buffer size - I know I might bore some people with this topic.
See when the plugin uses both CPUs it does get more processing power but it also has to handle more things, divide up data, copy it around so both CPUs can access it, combine the data again to send it out. This MIGHT be the reason why you get crackles.
The DSP meter shows TIME, not CPU load, specifically time needed to process the data in relation to the time one buffer (i.e. 64 samples) represents. This time might be used up by the things I mention above (and not actual computation) hence the worse performance when you enable multi core processing. With a larger buffer size that time would be a way smaller percentage of the whole buffer, hence a lower „DSP load“.
Edit: And yeah, what essel said doesn‘t really make sense, the only thing the DAW „manages“ is that it starts the thread where the main plugin process is run on, otherwise it can‘t just make the plugin use more CPUs somehow, that has to be coded in the plugin.
See when the plugin uses both CPUs it does get more processing power but it also has to handle more things, divide up data, copy it around so both CPUs can access it, combine the data again to send it out. This MIGHT be the reason why you get crackles.
The DSP meter shows TIME, not CPU load, specifically time needed to process the data in relation to the time one buffer (i.e. 64 samples) represents. This time might be used up by the things I mention above (and not actual computation) hence the worse performance when you enable multi core processing. With a larger buffer size that time would be a way smaller percentage of the whole buffer, hence a lower „DSP load“.
Edit: And yeah, what essel said doesn‘t really make sense, the only thing the DAW „manages“ is that it starts the thread where the main plugin process is run on, otherwise it can‘t just make the plugin use more CPUs somehow, that has to be coded in the plugin.
So to speak, running informations from cpu to external Dsp cores and back would further that time delay, and multiple dsp cards would performs worse than a single cpu thread? But are not dps's core designed to ''bridge'' data with each others, is that not the initial purpose to have multiple dsp's audio cards? In another post you mentioned Pro tools can process less plugin's from the Apollo than if processing from the cpu.normen wrote: ↑28 Oct 2017It might again be connected to the fact that Reason runs all plugins at a constant 64 samples buffer size - I know I might bore some people with this topic.
See when the plugin uses both CPUs it does get more processing power but it also has to handle more things, divide up data, copy it around so both CPUs can access it, combine the data again to send it out. This MIGHT be the reason why you get crackles.
The DSP meter shows TIME, not CPU load, specifically time needed to process the data in relation to the time one buffer (i.e. 64 samples) represents. This time might be used up by the things I mention above (and not actual computation) hence the worse performance when you enable multi core processing. With a larger buffer size that time would be a way smaller percentage of the whole buffer, hence a lower „DSP load“.
Edit: And yeah, what essel said doesn‘t really make sense, the only thing the DAW „manages“ is that it starts the thread where the main plugin process is run on, otherwise it can‘t just make the plugin use more CPUs somehow, that has to be coded in the plugin.
I'm sorry if I'm annoying you, it is very interesting to learn more about, thnx for
Check out this video, in it I explain what happens in digital audio and what happens with buffers.Re8et wrote: ↑27 Jun 2018So to speak, running informations from cpu to external Dsp cores and back would further that time delay, and multiple dsp cards would performs worse than a single cpu thread? But are not dps's core designed to ''bridge'' data with each others, is that not the initial purpose to have multiple dsp's audio cards? In another post you mentioned Pro tools can process less plugin's from the Apollo than if processing from the cpu.
I'm sorry if I'm annoying you, it is very interesting to learn more about, thnx for
Now with that knowledge - Imagine a DSP card is - as I said - exactly the same thing as an audio interface with analog audio processors connected, all the audio has to be routed through there as well. I'll make another video about latency, DSP cards and hardware/software monitoring at some point to explain that in detail.
- chimp_spanner
- Posts: 2916
- Joined: 06 Mar 2015
Wow! Really interesting video Normen! I think this should be required viewing for anyone who wants to understand how powerful their computer actually is. Great stuff!
-
- Information
-
Who is online
Users browsing this forum: No registered users and 7 guests