Needing excessive buffers for Playback and Recording

I'm having an issue wherein I have to have my buffers at 4096 to have no dropouts and even then, I still get the occasional dropout. This is with my CPU usage not even hitting 25%. This is particularly vexing because loading up a project that uses 85% of my cpu in Reaper with an obscene amount of plugins and such at a buffer of 64. 
 
For the sake of troubleshooting, the relevant computer specs are as follows:
4790K - overclocked to 4.7GHz
16GB RAM
Motu 1248 connected via USB
 
As I stated, the system is stable everywhere else and runs perfectly fine in reaper.

Run Latency Mon. 
http://www.resplendence.com/latencymon
 
Disable Video card HDMI audio. 

Just to be clear, when you say "dropout", do you mean the transport stops with a "Toast" notification from SONAR? Or do you just get an occasional pop in the audio from a dropped buffer or some MIDI notes don't sound or...?
 
If it's an actual transport stoppage, you should either see a CPU spike or the disk I/O icon flash red in SONAR's performance module. Then, if it's a CPU spike, I'd suspect some driver causing a DPC latency to spike or maybe an interoperability problem between SONAR and a particular plugin. If it's disk I/O, you might just need to increase your playback disk buffer size.

Motu drivers are really really bad on Windows, I´m running RME in my studio and have a Motu 828mk3 for live recordings,
RME rocks withb lowest latencies with Platinum
and the Motu always gives me problems..

RAID 0 should be OK (although I personally wouldn't bother with using a RAID array on a DAW or home PC, I prefer to backup).  Given your system specs, there is no way you should ever be having to use an audio buffer size of > 256 samples.
 
In my opinion, you should not be using SSD drives for your audio; system / application drive yes, but any drive that's going to have a lot of writes thrown at it should probably be a normal magnetic platter disk.  Was that your decision, or did somebody give you that advice?  Do you know the read/write speed balance for the SSD drives that you're using?  It's not necessarily that they'll wear out and stop being usable after a period of time (high quality modern SSDs have something like a 5 year whole-disk write warranty!), but that there's an awful lot of checking, copying, wear-leveling, and shuffling around of data required on each block write, and the minimum amount of data is always an entire block; SSDs have built-in data redundancy, so like a mini RAID system all to themselves.  What I'm trying to say here is that an SSD RAID array will not necessarily be a better choice for audio streaming than a fast SATA or SAS HDD.
 
FSB (i.e. RAM access) timings can be critical, and there's a relationship between the CPU clock speed and the FSB speed.  You are most likely having memory access/contention issues if you're seeing dropouts with a buffer size of 4096 bytes, so the first thing I'd suggest is to remove the overclocking from the CPU. 
 
If that doesn't help, try using a non-SSD drive for the audio, even a USB-connected external drive will do for this purpose.  Also, try removing the Motu interface and select a non-ASIO driver in Sonar (try using Windows WDM, i.e. crappy motherboard audio).
 
If none of the above helps to shed any light on the matter, it might be worth posting some more detailed specs here; mobo, memory, cpu, hard drives, raid controller, gfx card, OS, anti-virus s/w, attached peripherals etc.

Weird issue...
 
I'm not sure how you ended up at 4096 samples buffer - I would put that down to 512 and look for other reasons to crackles, it's not buffersize that is the problem. Read somewhere, not sure if about ASIO or some other reason, but just increasing isn't better - and much dependent on drivers if it locks the cpu busses for all samples to be transferred, more samples over a certain limit may be worse.
 
Next thing I come to think of is if the loaded instruments you use - creating a fresh instance in Sonar - have the same settings for streaming from disk, preload i memory or whatever.
I would test freeze one synth at a time, and see which is inflicting the most.
 
Next thing - any antivirus software and Sonar should be excluded there. I run no antivirus at all at daw - but my working machine I tried 5-6 different ones, and all create more problems than any virus I dealt with.
As a test I would turn off antivirus completely - and that improve things look to exclude the Sonar process.
 
And finally, different graphics libraries may have issues, and Sonar might use another than Reaper - look for graphics drivers updates. And as a test - choose the performance setting(Control panel - System somewhere) in Windows if that changes anything, it will look dull for a bit - but just to narrow down.

Good advice from lfm ^^^
 
You've got one thing going for you for troubleshooting, which is another DAW that does not appear to exhibit the same symptoms. They key is going to be finding out what's different. And by "different" I don't mean that they're different DAWs, but something else that's different between them.
 
That could be an antivirus program, for example. It could be re-scanning your .cwp file every time you make a change to it. Eliminate this possibility by *completely* disabling any antivirus software. If the problem goes away, configure the antivirus utility to excluded SONAR, the entire project directory tree, and the entire top-level folder where you keep your sample libraries.
 
I really don't think that Reaper is vastly more efficient than SONAR. Bear in mind that 95% of code execution time is spent in software external to the DAW itself: plugins, the audio interface driver, and Windows libraries. Efficiency differences between DAWs are therefore going to be very small. CPU usage will vary drastically, however, with different effects and soft synths.

Thanks for all the help, guys. I found out that VST3 Antares plugins (in this case, harmony engine evo) don't play well with Sonar X3 and Plat, so I had to replace each instance with the VST2 version. Wow that bug caused me a lot of headaches.

Haha. Well at least I finally got there. Also, it would have been the last thing I'd wanted to do because I have way too many plugins to effectively troubleshoot. I just kinda found the solution by accident.

Haha. Well at least I finally got there. Also, it would have been the last thing I'd wanted to do because I have way too many plugins to effectively troubleshoot. I just kinda found the solution by accident.