I had some very large files in Sonar x2 (recorded in 192k), and I tried opening it in Sonar x3 (when updating recently).
Files that constantly crashed in x2.
 
On first run the performance was absolutely incredible.
I could put literally as many effects on each track/bus that I wanted, including:
* As many prochannel effects as I want.
* As many 64 bit effects as I want. - Even putting 4 of them in 1 track (doing this on as many tracks
as I wanted).
 
Previously SonarX2 was putting way too much load on the first core (which caused the crash), and
on first run this was not an issue. - I have a dual CPU system (8 cores total).
 
Why is this happening, and can I fix it? - I converted the file down to 96k and I'm having performance issues even there.
 

Do you have the file settings at 32 bit or 24 in preferences > File > Audio Data.

gswitz
Do you have the file settings at 32 bit or 24 in preferences > File > Audio Data.

They are all on 24.
I notice they can all go up to 64, and admittedly I don't know what they do.
I am "supposed" to be recording 96/24.
 
Should I change them?
 
EDIT:
I have tested all modes (32 and 64). This has absolutely no effect on the problem. 

What effects have you added to the project? Some effects are CPU-intensive and only a few of these can be noticeable. If you hit "E" (to bypass plugins) does the CPU load alter drastically?

Here's one tip...
http://forum.cakewalk.com/FindPost/3105274
 
Another is to try running LatencyMon
http://www.resplendence.com/latencymon
 
Your problem is likely to be either IO or DPC Latency caused by one driver or another. I've had trouble in the past with a very stable system because I introduced a new mouse. LatencyMon can point you towards the problematic device.

Hi Guys, I just received these answers now.

mettelus
What effects have you added to the project? Some effects are CPU-intensive and only a few of these can be noticeable. If you hit "E" (to bypass plugins) does the CPU load alter drastically?

Yes it does massively improve things. But as mentioned in the first run I was running WAY more of them (the really intensive ones). - And in 192 not 96.
I don't see what could have changed between now and then.
 

gswitz
Your problem is likely to be either IO or DPC Latency caused by one driver or another. I've had trouble in the past with a very stable system because I introduced a new mouse. LatencyMon can point you towards the problematic device.

Thanks, I will have a good look at both of those now.

Hi again.
 
Here are screenshots of the cpu load on the file (when setting the
file up like I did on first run).
FX OFF:

FX ON:

As you can see above the first core is doing all the work.
And I do remember it being evenly distributed on first run.
 
 
Latency Monitor:
I played around with this and multiple drivers are being flagged.
The most serious was easy to disable (floppy disk driver), however
the next 2 highest seem tricky. - Disabling the first didn't do anything.
The next 2 highest are "storport.sys" (highest by about 3 times), and "nvlddmkm.sys".
Storport seems to do many things and the other is related to the videocard
(though I haven't researched it much).
ALSO: If  I go to the CPU page (in it), it reconfirmed that Sonar's cpu load
diagrams are correct (first core using everything).
 

1) Core 0 is the work horse for Windows. This is a simple fact you can never win.
2) SONAR is a host program, so CPU/RAM usage reflects your system, not SONAR.
3) Some plugins are scripted to do their grunt work on Core 0 as well... Another battle you cannot win, but can be mitigated by judicious work flow.
4) Cakewalk partnered with Intel to pioneer many CPU optimizations, and X3 is very evenly loaded for threads it controls (SONAR cannot override a plugin, only host it).
5) Many plugins are designed for use during mixing, so running low latency, i.e. "tracking" mode, with them can spike CPU loading immediately.

I am typing this on my cell since the forum is not working properly on any browser. You are using a nicety that SONAR provides users and assuming SONAR is the only contributor. It most certainly is not, and even the fastest machines can be brought to their knees with improper plugin usage and work flows.

Work flow and plugin usage is a better focus for "resolution." Even with high CPU usage, that meter is immaterial as long as you are not experiencing crackles or dropouts during play.
 
Edit: Could log in on the computer after posting... if hitting "E" to bypass plugins shows a drastic change, optimizing latency for "mixing mode" would be advisable (bump up the ASIO buffer to 128, 256, 512, or higher in Preferences->Audio->Driver Settings->ASIO Panel...). If more tracking work is required while mixing, bypassing plugins with "E" is the quickest way to mitigate dropping the ASIO buffer to a better tracking setting (without the CPU hit).
 

Some FX and some synths work first core harder in my experience. In general my first core carries a little more load. Not like your image though.

Did latency Mon say your computer was green for real time audio? On the drivers tab, what are the worst offenders? What are the measurements?

Also, have you tried bumping up your buffers to the max for your interface? This can impact cpu usage.