PassiveDrift
I'm having the same problem, even if I use core parking. I wish that someone from Cakewalk would respond to this problem. Core 1 is always 50% - 75% higher then the others. I see it the most with AD2 or  multiple FX Plugins. Win 8.1 and Win 10pro, ASIO drivers. Manchester, Computer set to High performance.
 
 

Of course I can't speak for Cakewalk, but I think they can't control what other plugin manufacturers code into their products. Windows OS may have a hand in this as well. My example would be that when I use Izotope's Ozone 5 VST3 plugin for mastering within Sonar, core #1 is usually spiking, especially with "look ahead" type settings. There are limitations to what may be possible with your audio interface vs. Plugin settings + Windows OS.

PassiveDrift
I'm having the same problem, even if I use core parking.

Hi passive drift. You want to disable core parking - not use it.

noynekker

PassiveDrift
I'm having the same problem, even if I use core parking. I wish that someone from Cakewalk would respond to this problem. Core 1 is always 50% - 75% higher then the others. I see it the most with AD2 or  multiple FX Plugins. Win 8.1 and Win 10pro, ASIO drivers. Manchester, Computer set to High performance.
 
 

Of course I can't speak for Cakewalk, but I think they can't control what other plugin manufacturers code into their products. Windows OS may have a hand in this as well. My example would be that when I use Izotope's Ozone 5 VST3 plugin for mastering within Sonar, core #1 is usually spiking, especially with "look ahead" type settings. There are limitations to what may be possible with your audio interface vs. Plugin settings + Windows OS.

Agreed. When the ThreadSchedulingModel parameter is set to 2 for multicore threading, Sonar on its own does a good of spreading the load across all cores. Some other plugins however don't do as well. Ozone for example wasn't coded to take advantage of a multicore processor. I has contacted them back in version 5 and that's the answer they gave me. I have Ozone 7 now and it's similar.

What's your ASIO buffer size? If it's too small, the CPU has to work harder to keep it supplied with data, and that's not work that can be spread across cores.

dlesaux
 Ozone for example wasn't coded to take advantage of a multicore processor. I has contacted them back in version 5 and that's the answer they gave me. I have Ozone 7 now and it's similar.

Thanks for the heads-up! I was just about to upgrade to O7. Shall wait for a version where they clearly state it's been addressed.

Kylotan
What's your ASIO buffer size? If it's too small, the CPU has to work harder to keep it supplied with data, and that's not work that can be spread across cores.

Buffer size in my case does not seem to be relevant to the core 1 problem. 

I only have this issue when using Rapture.

I'll say this, when you're in the heat of mixing and recording it may not see the clear problem.
 
I just tested the crap out of the core 1 problem. frankly I can pile on the plugins with little problem some use a bit more core one then others. I also set up a few soft synths, I only use the ones that come with Splat with not much core movement at all. I ran around 12 tracks of a 4 minuet song using all Pro channels on and set to different settings and didn't get not much core movement.  but when there was core action core one is always higher.
 
AD2 is always the problem for me. and for me there are a few Waves plugins that push core 1.
Ik plugins worked great. BUT my ik tron and moog crash Splat. none of the CW plugs or soft synths had core problems. I did not check them all or everything just a random test.
 
I guess I want to know how to get AD2 to work without clipping core 1?
 

gswitz
I only have this issue when using Rapture.

I tested both the Rapture VST 3 and ? versions that I have that came with Splat with out hardy any core movement but the movement was  on core 1. I really don't use soft synths that much so my test is just what I see with no real load.

I do know that in the past I was having performance issues not related to SONAR but having audio glitches. After hours of trying to find a work around for my QUAD CORE multi thread CPU (8 cores), I hypothesized that perhaps the issue wasn't related to SONAR at all but my computer doing basic background stuff not getting enough CPU juice.
 
I looked around and sure enough, there is/was a setting for the MAX cores for SONAR to use.  I remember tweaking this number down to 7, 6 and then 5.  6 gave me my lowest latency without audio glitches.  Once I changed this parameter in the .INI file (I think that was where this was), my system became stable again.
 
I have since done a rebuild with a 6 core processor and faster clock and no longer need to throttle down the max number of cores available for SONAR.  There is no doubt, that the lower I set latency, the more sluggish my DAW becomes.  Editing MIDI notes in the PRV becomes painstakingly jittery, etc. So, you would think that the bakers would have some type of dual latency setting available for users to have one LATENCY setting for recording audio and another LATENCY setting for non recording mode?  Just a thought, and it was save a ton of time of toggling this back in forth in the audio settings area.  This would make for a smart way to set it and forget it to tune your DAW PC depending on the mode automatically, no?
 
Jim