Another possibility is plugins. I find, as much as I like Izotope Ozone 5, there are a few settings, particularly in dynamics and volume maximizer modules that cause a lot of pops and clicks (they're higher resolution and need more ticks). The same goes for some VSTs like U-He Diva...it sounds great, but man, at the higher resolution audio settings, ...ssssst-t-t-t-uuuuu-tttt-t-t-te-rrr-r-r-rrr....
 

Neirbod,
 
One more thing to consider in case you haven't run down the problem yet...
 
Are you doing anything with your interface that might cause the problem? For example, is your interface output gain above 100% or are your routing multiple outs to the same master? That can be hard to find b/c it isn't actually happening in Sonar and could cause clipping.
 
Sometimes my external sends end up routed to my master outs and when I audition I hear clipping b/c they are mixed in with the masters. If I bounce to tracks and select the master bus, I don't have the problem because the extra summing only happens at the interface where the sends are summed with the master bus and sent to the master outs. The Master Bus isn't clipping... the master outs on the interface are because the external sends are being summed in again with the Master Outs.
 
So, in Sonar, there is no clipping to find. I would have to see it in the interface software.

Well I stupidly overlooked MIDI playback buffers, now this is sorted I'm rock solid and my latency settings can now be reduced again...

JohnRick
I can only chime in and say that I have basically the same setup and problem as Nirmod - except that I'm running a UCX, instead of UFX. Things have been crystal until X3d so it's quite obvious the boys/girls ****ed up this time. I find it also highly amusing that people recommend checking buses for clipping, make sure they have a TI card, bypassing FX etc.etc when it's obvious things worked flawlessly with the exact same setup as before and the only thing that has changed is the software version. For me the pops come for such small things as activating the audio engine. Horrible. 

Glad I highly amuse you.  
 
I asked a question about the bypassing of effects because that HAS caused dropouts and such for other folks in the past, and since I have no idea of what is actually loaded into the problematic project, I thought I would ask - which I also prefaced with an indication that I may have missed other relevant information.  
 
And, checking the results of bypassing the effects and turning them back on is perhaps 1 minute of time - likely less than the time to put your post out there.
 
Lastly, just because an issue is exposed in X3d does not necessarily mean that it is CAUSED by X3d.  It certainly may have been, but there have also been issues with deficient plugin code where it shows up after a particular Sonar update, but is still an issue with the plugin - just uncovered by some slight variation in Sonar.  
 
If I did miss the original poster's explanation of the project at hand having the issue, then I will again apologize - I DO stand by my question about bypassing effects being a reasonable one - the OP could have skipped it if it did not apply.
 
Bob Bone

CakeAlexS
My issues are resolved! (Famous last words)
I have absolutely no idea why (could still be my PC) but I'm wondering if values are not persisting in Sonars database, or some sort of value corruption. This is totally pie in the sky, not much logic to it, but try this...

Open Sonar, Open a project
Go to Preferences -> Sync and Caching
Take note of play and record buffer size. Double them (or something)
Click OK
Go to Preferences -> Driver Settings.
Click ASIO Panel.
Click OK to close preferences.
Play your project a little.
Close Sonar.
Open Sonar, Open a project.
Go to Preferences -> Sync and Caching
Put ye olde values back into play and record buffer size.
Click OK.
Play project.
Close Sonar.
Stand on one leg.
 
Now is there a now difference of have I sent you on a wild goose chase?
(I suspect people have different scenarios here, however it may help somebody, or maybe it's just my imaginary friend).
 
This post of you and a driver downgrade to the focusrite mix control 2.4 saved my life,
thanks alex

Hi, no legacy firewire driver here,
but with File -> Clear Settings or even File -> Restore factory defaults
the actual Mix Control 3.3 runs fine now.......
awesome!

Update - I contacted CW and RME and about this issue and both companies have been quite responsive. They dug into it and found an issue having to do with how Sonar starts and stops ASIO. Apparently it is different from how most other DAWs operate. I don't know if this is a bug or just a different approach. I won't go into much more detail as this is mostly over my head and I know just enough to be dangerous. However, I thought people here would want to know that CW has found the root cause and is looking into a solution.

FYI the effect is related to how many channels are open in your interface. For RME users, in the controls panel (not total mix) there in an option to use all available channels or a subset of them. Reducing the number of channels greatly reduces the problem to the point it is almost not noticeable on my system. This may partially explain why some people see the problem and other do not.

Well it's interesting that it seems to be an issue with one company's drivers. I've been using my focusrite saffire pro 40 with ASIO pretty extremely recently and have had no such issues. I would have though ASIO protocol works in identical ways for any sound card.
http://en.wikipedia.org/wiki/Audio_Stream_Input/Output
 
>  I thought people here would want to know that CW has found the root cause and is looking into a solution. 
 
I'm not saying the OP is wrong however, it's just I can't see it myself (and I could be wrong). More detail needed I guess...
Would Cakewalk care to comment as this would appear to be a serious issue if true? (just weird how many people remain unaffected).

All - I would just like to add that I'm also experiencing cracks and pops, where I had experienced none previously. Everything is USB for me.  I'm experiencing it even on files that are brand new files with just one audio track and nothing else.  I've compensated by backing off on the latency. However, I used to be able to have super fast latency settings. 
 
I am wondering if a couple of us could reproduce it down to the most basic circumstances for each of us, like I've reduced it to a brand new file with only one audio track.  What other variables might be contributing, etc.  I can't speak to the firewire folks, but USB audio interfaces have been rock solid for me with no clicks or pops until recently, like I mean the last patch.

Guitarmech111
Neirbod, what control panel are you talking about? Windows? I want to try and limit some of the outputs, or are they paired by ins/outs?

Not the Windows control panel.  The RME settings panel.  You should see an RME icon in your tasksbar at the lower right.  This is where you can manually set sample rate, chose to apply DSP effects to the recorded tracks or not etc.
 
I don't know why RME drivers seem to be the only ones affected by this.  RME stated something along the lines of Sonar being the only DAW they know of that stops and starts ASIO, and that other DAWs typically keep it running.  There was some setting in Sonar related to the "arm tracks while transport is running" option that apparently could be tweaked to help address this.  I know just enough to be dangerous about this, but Noel Borthwick at CW and Matthias Carstens at RME were emailing about it (I was copied on some but not all emails), found the root cause, and were working on a fix.

neirbod
There was some setting in Sonar related to the "arm tracks while transport is running" option that apparently could be tweaked to help address this.

Ah.. now it's making more sense!
 
"allow arm change during playback/record" is a common workaround for dodgy drivers.
 
Years ago older versions of Focrusrite Mix Control had some nasty bugs such as lag when pressing SOLO buttons, and that was the workaround until Focusrite made the fix and it all started working.
 
OK you will be expecting a fix for RME, at least they are working on it.
 
RME users experiencing issues should try the workaround:
Preferences -> Project -> Record -> Allow arm changes  during playback/record = Untick.
 
Cheers...

> This is not likely an issue of dodgy drivers as it is a non standard DAW ASIO practice SONAR uses.
 
Well RME is seemingly the only interface company having issues right now, and like I say the EXACT problem happened with Focusrite which they fixed. RME pointing to "allow arm change during playback/record" is a total smoking gun. Did RME test their drivers with Cakewalk? Obviously not until now. Go figure! :)
 
BTW ASIO is protocol, there really isn't a "non standard" way of consuming it, it either works or it doesn't And Cakewalk supplies an off button as a workaround for those drivers that do not support Cakewalk (or are buggy) so they've covered that scenario as well.

Expect a fix from RME and not from Cakewalk, and when RME releases the fix and it works without any change in Cake's code, then expect everybody to somehow believe it's still Cake's fault (as is the norm) even though what they do is actually to help the third parties to fix their own issues when consuming Cake's hook in points :)
 
Cheers...!

BTW all DAW vendors will do things slightly differently, this "standard" sounds like something mythological, and a protocol is a protocol that either works or it doesn't. It may well be that Cake is doing something better than other DAWs (and like I said, they supply an off button!). This really does sound like a flimsy excuse from RME somehow trying to explain why their hardware is not working correctly with Cakewalk, esp when they give this workaround that Cake provides. If they'd given any other workaround I would have hesitated with my comments.

Focusrite I remember owned up to the issue pretty much straight away, and said they were working on a fix (admitted their fault) which they took about 3 months to fix at the time. As I say again, RME is the ONLY company experiencing this issue, I feel they are introducing smoke and mirrors at this point if this is indeed what they actually said (we can't really confirm as we have no direct quote), and I look forward to them making their drivers compatible with Cakewalk in the new future.

Guitarmech111
LOL

 
ABOVE THIS IS THE LAST WORD!!!! :) :) :)
Have a great week Conley...

Well as I said, "we can't really confirm as we have no direct quote" however recommending the disabling allow arm change during playback/record clearly points to the actual issue with the driver (and the fact that other companies drivers are working fine). Plus they clearly never tested the driver with Sonar 3.
 
Every company has had a dodgy driver one time or another, even Focurite, there's no shame in that. It's how they play it out and how transparent about it is what makes a companies reputation IMHO. I have had not seen any official response so I shall take everything I hear with a pinch of salt until we do.

Cheers...
 
(Edited as I wrote "Cakewalk" instead of "Sonar").