i have numerous performance issues and lots of dropouts
when not playing with latest Sonar (05.2016).
not that those issues are only occured with latest update -
but lets say they didn't disappear with latest update.
while i understand how hard is usually to figure out
whats happening on remote PC, i did some research
that i hope will help Sonar developers to understand
the roots of issues.
general description: while working on one project i
faced difficulties working with Sonar but had no time
to understand the cause for that. after i finished project
i realized that my PC spends lots of resources on Sonar
when i even do nothing. so i saw that if i open that
project and just do nothing then CPU load is around 60-65%!
so i started experimenting with various plug ins by turning them
on and off. i also had and have lots of drop outs.
please see details below.

------------------ MEMORY -------------------------------
* the Audio folder contains 103 audio files with total size of 6.67 GB
* when project is loaded the RAM usage is 7 692 MB
i have no idea why RAM usage is so large but it correlates with Audio folder size.
the interesting thing is that there are bounced tracks and previously imported
audio tracks there (my project is remix and initially i imported lots of
audio tracks from original track. now i deleted that tracks but audio files
are still left in Audio folder).
as for bounced tracks - i had some tracks frozen for some time
but now all tracks are not frozen so i expect that there is no need in
"Serum 3 (Bounced, 77)" kind of files.
anyway, if speaking about Audio folder - files like Crash drum audio sound
are so small that we may not count them. for example
"crash-019 (91).wav" is 89 kb of size.
if not count bounced audio and previously imported (but now not used) audio files
then rest files are less than 1MB in size.
 
CONCLUSION: it is unclear why Sonar uses so much memory
 
------------------- CPU ----------------------------------------
so i have this system:
* OS: Windows 10 Pro x64 bit
* CPU: Intel Core i705930K
* RAM: 64 GB DDR-4
* System drive: 512 SSD
* Project drive: 2TB HDD (7200)
* Screen resolution: Ultra HD
* NVIDIA GeForce GTX 960 video card
* TC Electronic Konnekt 6 sound card (used via Firewire). driver for
windows 7 is used (as they didn't have it for Windows 10 yet)
* SONAR: version 22.5.0 BUILD 45 [2016.05] - x64
 
project that i have has 57 tracks and 14 buses.
no track is frozen.
most of tracks are synt/instrument tracks.
8 tracks are audio tracks.
 
now here is what i do and what are results in Task Manager utility
(NOTE: music is not playing, this is just the IDLE mode!):
1. just opened project and turned off all plug ins in FX bins and prochannel
CPU: 15-17% (down to 0% when inactive)
2. turned on prochannel
numbers are same as in (1)
3. turned on Soundtoys Decapitator plugins (19 instances)
CPU: 19-24%
4. turned on FabFilter Pro-Q 2 plugin (51 instance) - my go-to eq
numbers are similar to (3) - 22-24%
5. turned on Waves dbx-160 stereo plugin (8 instances)
CPU: 27-32%
6. turned on Soundtoys Echoboy plugin (15 instances)
CPU: 29-34%
7. turned on Nugen Audio element plug ins (4 monofiers, 3 stereoplacer, 4 stereoizer)
CPU: the same as in (6)
8. turned on rest FabFilter plug ins (Pro-C 2, Pro-L, Pro-MB - 13 instances in total)
CPU: 32-38%
9. turned on Softube Drawmer S73 (13 instances)
CPU: 40-41%
10. turned on Waves Reel ADT, H-Delay Stereo and Abbey Road Plate reverb (each by 1 instance)
CPU: 43%
11. turned on FabFilter Pro-Q 2 and FabFilter Pro-L on Master bus
CPU: 43-45%
12. turned on 14 rest Soundoys plugins (pan man, phase mistress, crystalizer, devil-loc, radiator)
CPU: 48%
13. turned on rest 17 Waves plugins (puig child, puigtek eq, manny m delay, center, cla-3a, jjp-bass, cla-effects, h-delay, center, cla-bass)
CPU: 56%
14. turned on rest plug ins (couple of Imperial Delay, one Blackhole reverb, bifilter2, FuzzPlus3)
CPU: 60%
 
CONCLUSION: when not hitting Play button even once i have Sonar taking 60% of CPU (this number varies of cause)
for the project and lots of dropouts (while i made items 1-14 i had about 30 dropouts).
i believe this is not normal.
 
----------------------- OTHER ISSUES ------------------------------------
* when turning on/off plugins in Console view audio dropouts occur
from time to time. note that i'm talking about situation when
nothing is played - i'm just enabling/disabling plugins.
interesting thing: when dropout occurs the CPU usage goes down to 1-2% or so.
in other words it becomes as expected
one more interesting thing: if after drop out you switch to some other application
and then back to Sonar, CPU usage starts increasing again and in couple of seconds
come to the state that was before drop out
* audio dropouts also occur when not playing but doing some
trivial actions: saving project, scrolling console view
----------------------- SUGGESTIONS -----------------------------------------------
* when i select/touch anything on track in Console view (for example turning on plug-in
in FX bin or enable/disable FX bin) the track must be selected
* "on/off" buttons states for FX bin and ProChannel modules are not that recognizable on
the dark theme. what i mean is that as long as there are a lot of details in UI
then gray/orange color switch is not that easy to see. i would expect the background color
of the buttons to be changed rather than icon color
* if FX bin is disabled then i would expect to clearly understand that plugins are also passed by.
while it is easy to see when plugins are disabled (bg color is gray), it is not that obvious
when plugin itself is enabled but its FX bin is disabled. in this case bg color still remains orange
but a bit different orange. i have to say that these two orange colors don't differ that much.
i suggest that if plugin is enabled but its FX bin is disabled then plugin must have gray background
(singaling that it is omitted) but with either orange outline or orange dot (signaling that
the plugin is actually enabled still)
* scrollbars bar color is not that different from scrollbar's emtpy space color. on large screen
it is sometimes hard to point the bar by mouse

Simply too many issues to handle in one post. You have a lot of plugs going and many of them will have big latency issues.You can't track like that and if you are now mixing you'll need to really increase your buffers to prevent drop out. Why not break this down into a few questions. 

And please include config info such as project sample rate, record bit depth, ASIO buffer setting....

The engine is on even if the transport isn't because you may want to hear instruments when you play a MIDI keyboard or virtual controller.  Or maybe you want to hear reverb tails after hitting stop, or you want to input monitor a track and hear your effects.  So, the CPU load isn't unexpected when you have a lot of plugins.  What latency are you running at?  if you are getting a lot of drop outs, you may need to raise the buffer size.
Since you have a lot of audio, disk performance is critical, so you'll want to be sure that's performing well by running a utility such as HD Tune.
 
There's a lot of helpful folks here.
Keith
 
 
 

update:

* installed asio4all, set buffer to 2080 samples instead of 512
* DPC latency checker says "This machine should be able to handle real-time streaming of audio and/or video data without drop-outs."
the utility shows current latency a bit less than 1500 millisecs
* Sonar reports Asio reported latencies: Input = 0, Output = 43.3 millisecs
* Sonar now takes 48-49% of CPU usage in idle mode comparing to previous 60%
 

* RAM usage is now 7848 MB

biozel
update:

* installed asio4all, set buffer to 2080 samples instead of 512
* DPC latency checker says "This machine should be able to handle real-time streaming of audio and/or video data without drop-outs."
the utility shows current latency a bit less than 1500 millisecs
 

 
I recommend you uninstall ASIO4ALL. Your Konnect6 should have native ASIO drivers, and ASIO4ALL will buy you nothing, and may cause more issues.
 
First, understand that the DPC latency (a measure of how fast the CPU is able to respond to processing requests of all types) will be in microseconds (us), not milliseconds. Despite DPCLAT saying that's good enough, that number is quite high for a DAW. In my experience, most machines stay under 200us peak pretty easily, and a good setup will stay under 100. My new machine is amazing in this respect, running under 30 most of the time.  The CPU usage meter in SONAR is a measure of how much of the time available to process a buffer of audio is currently being used, and the time available is basically the length of a buffer. At typical buffer settings of 64-256 samples (approx. 1.5 - 6ms at 44.1kHz) a DPC latency of 1500us (1.5ms) is going to be a problem. At 512, somewhat less so, and at 2048, your CPU should not be breaking a sweat almost no matter what's in the project.
 
So I'm not sure why your CPU is running so high with the ASIO buffer up at 2048, but you definitely need to look into lowering the DPC latency in any case. Generally, this means looking for unnecessary system drivers that are causing it, and shutting them down. The most common offenders are Bluetooth and WiFi. Try running the free LatencyMon which gives more information on what's causing the latency than does DPCLAT.
 
EDIT: Also meant to mention, you should disable Speedstep, C-states and Turboboost in BIOS, and make sure CPU cores are not getting parked. You can Google these keywords against site:forum.cakewalk.com to find more info.

From http://www.tcelectronic.com/desktop-konnekt-6/support/

Note: Currently, TC Near is not compatible with Windows 10, and we recommend users not to update. Subscribe to our newsletter to receive information about software updates.

If this is the case, may want to replace the interface or install a supported OS.

Seriously, though, do you have enough plugs going on here?  I'd freeze every one of those tracks, or better yet, render them all out and mix them in another project without all those plugs. Whatever you choose to do to get around it, Sonar has zero control over what those plugs do with the signal, so pointing that particular finger at Sonar misses the real culprits, imho.
 
Your system has 64gb of ram. 7.9 GB of memory usage is not unusual in apps of this type. Note that that number may not be the actual memory usage of sonar, only what it thinks it has. The OS has tricks to map data in and out of memory depending on available RAM and the amount of memory all the processes are asking for. It's the working set that's the real number. In a system with the huge resources you have available, the OS will be pretty generous in what it allows processes to have and you may never see a page fault even if Sonar were to load the entire set of clips into RAM. That's why having a boat load of RAM is such a good thing. Whatever else is going on here, RAM usage is not your problem.
 
The dropouts are usually an issue with the driver being unable to feed samples fast enough. That's almost always because your ASIO driver is contending with other drivers for interrupt time. That happens well under the application layer, down in the kernel of the OS. The advice given about disabling devices you aren't using is very good. Also, take a look at your on-board sound  devices (if any) are enabled, and if so, disable them, ideally at the BIOS level. Also, it seems like every software company and his brother has an update service installed these days, hammering on the network looking for updates. Turn those off, along with services like the search and indexing services, plus any others you don't need. There's a list somewhere of services you don't need while you're DAWing away. I saw somewhere that someone created a batch script to turn unneeded services on and off to make things simple. That kind of approach makes things pretty easy. 

Hi kevinwal - that rumor of a batch utility to turn services and/or start items on or off may be referring to something I initially wrote in C# for use on machines when I was running Sonar on XP Pro for a 32-bit computer.
 
That utility worked well under XP and all the way into Windows 8.1, but to be honest, I have not needed to use it for several years now (though it does still work).
 
The reason I have not been using it is because once I moved to a 64-bit environment, with computers that are running 32 GB of memory, and split programs/samples/content across multiple disk drives, my performance was quite adequate, and I just quit bothering to do most tweaks altogether.
 
There are a couple of things that I believe the original poster would benefit from understanding.
 
1.  With 64 GB of memory, I would quit worrying about memory usage altogether.  You have WAY more memory than needed for any project I would ever have running through Sonar with that setup on MY computer.  32 GB is PLENTY for everything I do.  Having the extra memory is wonderful, but if memory is not the performance issue for you, (which I don't believe it is for you), then I would just quit worrying about it.  Sonar can load all it needs to into the memory you have, and will stream samples as needed from disk, and read/write projects as needed.
 
2.  For the REST OF TIME, you will have two basic modes of operation: Recording/Editing - and Mixing/Mastering.  The processing needs ARE different when you are Recording or Editing, versus Mixing or Mastering.  You will need to adjust your ASIO Buffer Size to something small enough to support low latency recording/editing, and then when ready to move on to Mixing/Mastering you will need to adjust your ASIO Buffer Size to something WAY bigger, which will give you lots more latency, but at the same time will give you the proper buffer sizes for running plugins that induce lots of latency - such as convoluted reverb plugins.  ANYTIME you move between Recording/Editing and Mixing/Mastering, you will need to set the ASIO Buffer Size accordingly - small for tracking/editing, and huge for mixing/mastering.
 
It would seem to me that if you approach projects a bit differently, you will find that your current computer has WAY plenty of horsepower to create incredibly complex and beautiful projects, but you need to adjust your approach to that of always keeping your latency LOW for recording and HIGH for mixing/mastering.
 
When recording/editing:
 
1) Get your latency low, through a combination of a small ASIO Buffer Size, a reasonable Sample Rate, and simpler plugins. I use an ASIO Buffer Size of 128 (could go down to 32, but 128 is easy and I find the latency is fine for me - I think my total roundtrip latency runs around 10 ms.
 
2) Don't do your initial recording with a whole bunch of plugins that add lots of latency.  Be aware that each plugin will add some, and that's OK to a point, but some plugins are simply NOT intended to be used during recording.  These plugin types would usually be those that use something called 'Look-Ahead Processing' or otherwise chew up lots of CPU, and would typically be things like convoluted reverb plugins.  Remember, your MIX will be where you sculpt your sounds with your plugins, other than some basic (and latency-lean) plugins to have perhaps some sort of delay/reverb that does NOT use the look-ahead processing.  SO, when choosing which plugins to use during recording, look for those that will help you get your signal recorded, but that don't jack up latency to do that.  Use a simpler reverb until you finish recording, and then you can swap that out for the fancier one that adds tons of latency once you move into the mixing/mastering phase of any given project.
 
 
When DONE with recording and editing, and ready to move to mixing/mastering:
 
1) Adjust your ASIO Buffer Size to 1024 or 2048 - big is FINE, because you won't be trying to record at this point in your project, you don't care if it takes a half-second before playback starts.  Having the huge ASIO Buffer Size for mixing/mastering gives lots of room for the more robust plugins to be used.
 
2) THIS is the point where you can swap out some of those low-latency but more basic plugins you used during recording, for the really powerful convoluted reverb plugs that DO add lots of latency.  Again, you are not trying to RECORD tracks during mixing, so who cares if your latency is 40-50 milliseconds or higher.  It is a non-issue for mixing to have high latency.
 
I would steer far away from ASIO4ALL if at all possible, and use a dedicated audio interface that has drivers that are SUPPORTED for the level of the operating system you are running Sonar on.  ASIO4ALL is really a program that basically acts as a wrapper - making programs THINK they are using ASIO drivers, but really underneath the covers, ASIO4ALL is using your CPU to do all the data conversions needed, and this is FREQUENTLY not going to give you smooth streaming audio, such as what is needed for recording in Sonar.  Some folks have reported issues simply having ASIO4ALL installed, even though they are using the ASIO drivers for their audio interface.
 
IF your audio interface does NOT have drivers for Windows 10, then as was posted earlier by someone else, either roll back your Windows to Windows 7 or 8.1, OR go buy a new audio interface that DOES have ASIO drivers that work with Windows 10.
 
I sincerely hope the above makes some sense - it IS 5:00 in the morning here, and I have NO idea why my eyes are even open at this point, since I have to get up in 2 hours and have not slept yet.
 
Please feel free to ask some questions, if you want me to take another stab at explaining any of the above.
 
I FIRMLY believe that if you match your dedicated audio interface to a version of Windows that interface has supported drivers for, AND you adopt an approach of Low Latency when recording/editing, and High Latency when Mixing/Mastering, you should have an AMAZING capability on your computer to do some huge projects without performance issues.
 
Bob Bone