I've been suffering with dropouts, CPU spikes, and audio skips/stutters on my projects.  I've tried increasing my buffer to 2048, I bypass all the FX bins in both tracks and busses and it still makes no difference.  The audio pops, drops out, sometimes when there's a dropout all 12 meters on the CPU meter all spike into the red momentarily.  Then it'll be fine for a random amount of time - like 10-15 seconds, then it happens again - a pop and a dropout, maybe a CPU spike.  This repeats through the whole playback. 

My original subscription ran out in August 2017 so that's the last time I updated and that version up to that point worked perfectly.  I don't know if it's something in Bandlab's version, or it could have happened in an update after August and before Bandlab got it that did this and I wouldn't have known because I didn't update until Bandlab released the current version.

Has anyone experienced anything like this?  None of my projects seem to be immune.  It's not a memory / computer problem because a lot of these projects I originally did in Sonar and there was no issues at all.  I also use Studio One and I've demoed Reaper and both of those have zero issues or hiccups no matter how heavy the project I've dumped into them so I know it's not a power / memory issue. 

Was there anything changed in preferences perhaps in one of the updates in how Sonar handles memory?  Maybe there's something I need to re-check again?  

Also, my hard drive is an SSD so it's not an issue there. 

Thanks

Hmmm...digging through the menu I found two options unchecked - 64 bit double processing (which is strange because I thought I had it checked) and "Plug in load balancing" which I never remember seeing.  So I checked it and I'm trying a song and it seems to working smoothly at the moment amazingly.  

I doubt it was the 64 bit double precision. Maybe the load balancing?! I never remember that feature and Sonar always worked fine without it, but I guess when they added it, then it changed the behavior when it's not checked?  Anyway at the moment it seems to be running smooth so I'm going to keep my fingers crossed.

Always worth running latencymon or dpc latency checker to see if there are any devices holding up the cpu if this happens again.
 
I had a similar issue and found it was my usb wifi dongle...unplugged the dongle and the audio engine problems disappeared.
 
 

The MS updates have played havoc with many of my preference settings, not in SONAR but other programs and in Windows itself.  It seems I get them sorted out only to have MS surprise me with another update.

MS Windows (free version) also reloads Skype, Dropbox updates, etc on its own.  If I have a project running that's fairly heavy on resources, these will push it to create pops and stutters and even halt the audio engine.  Skype seems to be the worst about it.  I use Task Mgr to turn off all the unwanted apps before using Sonar each time.  It's a pain but it seems to help, and I haven't found another way to keep these from re-loading.  Unfortunately, Cortana re-loads immediately if you close it.

Thanks for the ideas everyone - it never dawned on me to run a latency checker which I should have anyway.  

I'm running Windows 7 and have pretty much everything turned off that's not essential to Windows.  Even my bootup is really streamlined so that nothing loads that's not absolutely necessary.  But yeah, there's no avoiding anything that sneaks in there. 

I got hit about a year and the half ago with malware and while through a series of fortunate events it ended up not being able to really attack my system, nevertheless I turned automatic updates on and installed a lot of anti-virus stuff so I know there was the potential of something being updated that maybe Sonar might not have liked but the thought of trying to hunt that down - I didn't even want to think of that yet lol.

I'm working today in it and it still seems to be running smoothly. 

I think the advice to disable the network connection is probably the easiest path worth taking.  Most of the background stuff that might run by stealth will likely need the network to phone home, so if no network available, it will likely go back to sleep instead of checking for updates or whatever.
 
If it is desirable to leave the network connected during a session, then doing some digging with Sysinternals Process Explorer or Autoruns to learn more details about startup and scheduled tasks may be necessary.  Streamlining your active tasks and processes for audio is always a good idea!
 
Aggressive anti-malware apps can be dealt with if they allow scan exclusions for your audio paths and programs, and avoid scheduled scans during audio sessions (I disable scheduled scans).

If networking can be done using ethernet rather than wifi that often helps a lot with dpc latency issues that cause dropouts. For whatever reason Windows processing scheduler seems to give wifi more PCI bus time than it does ethernet. I’ve had three PCs over the years that were fine running Sonar with ethernet networking, but wifi caused big dropouts. Changing the make of the wifi adaptor made no difference, and the built-in wifi adaptor on one far from cheap motherboard was the worst offender of the lot.

Without wanting to get into the PC vs. Mac religious wars I’ve not found wifi to be a problem on Macs when running DAWs, and even use wifi MIDI networking between iPads and Macs without problems. Which makes me think either MS or the hardware/driver makers could sort this out on Windows PCs if they put their minds to it.