emwhy
Oops my bad gunboatdiplomacy.....in the Abbey Road kit, switch your mixer setting to "init" and watch how much the first core comes back to earth! It's the mixer in that particular Kontakt library that causes me grief. I've stopped using that part of it and just process the Abbey Road stuff through SONAR's Pro Channel.
 

i will do that the minute i get home!

One thing to watch with core parking is Windows updates can sometimes turn it back on again.

I had to switch it off when I updated Win7 to 8 and again at the 8.1 update. Last week I noticed Sonar was only using two cores and despite the project being pretty lightweight absolutely hammering them to death complete with glitching and dropouts, while the Windows task manager showed under 8% total system load. So I checked core parking settings in the registry and found it was back on again. :-/

Which didn't entirely fix the Sonar problem, which turned out to be curable by letting Sonar write itself a new aud.ini which restored normality. No idea what the problem was, maybe the result of accumulated junk caused by importing settings from X1->X2->X3->Platinum, but easily fixed.

So if Sonar's reporting very strange or unbalanced cpu core activity it might be an idea to go into preferences and tell it to create a fresh aud.ini file (it keeps a copy of the old one as backup) then restart Sonar.

Yeah the onboard mixer in NI's Drummer libraries is a core hog. I have all of the NI effects in that mixer as standalone plugs and if I make up the same chain of effects in the ProChannel instead of using the onboard mixer, I don't get nearly the same load on my first core.

Hey guys!
 
Lots of great info. I'll try some and let you know how it goes.
 
PS
Looks like Core parking was already disabled...
 
/M

Something to keep in mind is that core usage is also a factor built into a program (to utilize properly or not), and SONAR is simply a host... it cannot control this in any plug. Core 0 tends to be the "workhorse" not only for Windows, but also many programs (since it exists on every machine), and often the "main" portion of a program runs there. Also, some processes must be run end-to-end, so if committed to a thread, that is where they will run to completion. A simple example is running batch processes with Audition... the core program stays in Core 0, but each process gets a thread, so on an 8 thread machine it processes 7 files at a time end-to-end with each core then picking up another job.
 
There is also a difference between seeing this and it bothering you versus this impacting performance. It would be nice to have a listing of "primary offenders" to Core 0 usage, but some of it is just watching how the Cores load when inserting/playing specific plugs. If they do become impacting, consider freezing synths or bouncing tracks and archiving the original to mitigate CPU usage. Some can also be achieved via workflow, since "simple" tends to be far less CPU-intensive than "complex."
 
With all that said... SONAR unto itself is very good at balancing core loading (and what it can control).

mettelus
Something to keep in mind is that core usage is also a factor built into a program (to utilize properly or not), and SONAR is simply a host... it cannot control this in any plug. Core 0 tends to be the "workhorse" not only for Windows, but also many programs (since it exists on every machine), and often the "main" portion of a program runs there. Also, some processes must be run end-to-end, so if committed to a thread, that is where they will run to completion. A simple example is running batch processes with Audition... the core program stays in Core 0, but each process gets a thread, so on an 8 thread machine it processes 7 files at a time end-to-end with each core then picking up another job.
 
There is also a difference between seeing this and it bothering you versus this impacting performance. It would be nice to have a listing of "primary offenders" to Core 0 usage, but some of it is just watching how the Cores load when inserting/playing specific plugs. If they do become impacting, consider freezing synths or bouncing tracks and archiving the original to mitigate CPU usage. Some can also be achieved via workflow, since "simple" tends to be far less CPU-intensive than "complex."
 
With all that said... SONAR unto itself is very good at balancing core loading (and what it can control).

mettelus . . . in all the threads here about CPU / Core usage, I've never seen it explained this clearly.
Thanks for that. On my system it's true that Sonar, and Sonar's included plugins generally provide balanced use of my cores. It's only when I add Ozone 5 to the Master Bus (during mixing phase of a project) that Core #1 starts to stand out much higher. It's a VST3 plugin, so I would have thought it would perform better, but there's no adjustment within Ozone 5 for core usage that I have seen, but the more usage of "look ahead" type features, the more CPU it uses.(My Fabfilter Pro-Q2 VST3 plugin has three settings that affect Core + CPU usage)

Hey Guys , I never had this problem but I too am suffering from my first core being alot higher almost 3x's more than the other 3 core's..
 This is even on a brand new project , If I add a VStI hit a few keys and I see my first core go alot higher..
 I called support which was very helpful but I still have the same issue,
 I made sure speed step was disabled . I also disable core parking which , Im not sure if it is disabled. I followed a youtube video were I had to copy a hex key find it in the regedit and then change the max value to zero, then find next , and see if there were more values that could be changed, Only found one to change.
 Now when I restarted and looked at the processors they still dont look even in the task manager.
I wonder if my cpu is going bad. Right now I cant even get a 20 track count. NEVER had this problem . 2.8 ghz quad core . What software should I run to determine if my cpu is going.. or what should I do , new computer?
 
 Thanks for your help .. John

Just to let you know if anyone's interested. I tried all sorts of things but the problem remains. I understand why this happends now because of some very good response in this thread. But just as djjhart above is writing. It feels like this has gotten much worse. I cant recall it being this bad ever before.
 
/M

Are you seeing this with specific VSTis or plugins?
 
One thread I remember from LONG ago talked about the ProChannel being enabled causing grief (in projects with fairly high track count). I cannot recall the specifics of that, but recall the person saying that disabling the PC for tracks helped noticeably.
 
If plugin-related, the quickest check is to hit "E" (global plugin bypass). If the core 0 drops substantially it is a good indicator. Freezing VSTis is another thing to try (some VSTis are CPU hungry).
 
I recommend saving the project as a new name first, then you can troubleshoot without worry for mucking the original project file.

Hey People.
 
If you are using multiple cores/threads on your DAW;
Also, don't forget that under:
 
Preferences->
Audio->
Configuration File
 
You need to click on the button at the top
that say's "Edit Config File".
 
Scroll Down to where it says "ThreadSchedulingModel" and 
change the entry to "2", then save and re-load the file
so Sonar knows that you are using a multi-threaded
processor, and that it is ok to spread
processor calls across ALL your cores/threads.
 
You will note that the graph in the Performance Bar that
shows your core number and their activity is more lively
spread across all your cores;
 
The 1st bar will Always be a little higher, or a lot,
depending on hard you push your DAW,
because certain processes in Sonar always use the 1st. thread.
 
...I am sure someone will be nice enough to chime in if
more info is needed.
 
Peace
Mel