Hey Gswitz - Thank you for your reply. Could you give me a little more info on some of your comments please? (When talking to me about this stuff, imagine you're trying to teach a child - because that's my level of understanding. But I'm very willing to learn...)
 

gswitz
 
I choose Record Bit Depth of 24 bits at the level and Render Bit Depth of 32 bits. Now... when I used an old laptop, I used render bit depth of 32 bits. For most of us, there is no advantage to using a Record Bit Depth of 32 bit if your interface only works at 24 bit.
 
I see all of mine (Record, Render and Import) are currently set to 64. So would you recommend I change mine to what yours are?
 
You should be able to rule out hard drive trouble by decreasing your File Audio Data write size. This should remove pressure from the drives. It's a useful step in troubleshooting. It's not sure to help, but it might.
 
What are the implications of doing this? Does this decrease quality? As you can probably tell - this is taking me out of my depth! But I will try it when I understand it better?
 
When I use Latency Mon on my computer
http://download.cnet.com/LatencyMon/3000-2086_4-75300293.html
My worst reported driver is tcpip.sys (I'm streaming a Craig Anderton Video) is 0.17ms.
 
So with me - do you think my latency spike is caused by my PC rather than Sonar?

 

OMG yes!! Turn these down from 64 to 24 as a step in trouble shooting. If you PC proves good for it, bump render back up to 32... but from a scientific perspective, 24 bit files should be able to reproduce everything a human can hear with room to spare. 64 bit is WAY over kill and could well be your whole problem.
 
If you still get dropouts at 24 bits you can step them down to 16 just as a test. I'm starting to think that going to 24 bit file rendering will suddenly free you up and you PC will work GREAT!!
 
The theoretical limit for reproducing everything a human can hear where you use every available bit at 16 bits is 96 dB. This means, if you have a well mastered CD on an Awesome Stereo, theoretically, unless you are listening above 96 dB (the volume of car on the highway) then humans will not be able to differentiate this from a recording with a higher bit depth.
 
In practice, most of us agree that this is not the case. 24 bit sounds better when you turn it up... and having a good clock matters too. Still, the point is there. The math behind the number is good. So it's called 'theoretical'.
 
For years I only recorded at 16 bits and was totally happy with it. Once 24 bit became available, I found it nice to have that increased headroom. I didn't have to push the clip ceiling so hard when tracking.
 
I don't want to type too much and make it hard for you to get out of this what matters...
 
What I'm telling you is turn BOTH RENDER and RECORD File Bit Depths down to 24 and try again.

Worst Latency spikes will really NEVER be caused by Sonar. The DPC problem comes from other DLLs that interrupt the system and take priority for one reason or another. There are lots of examples of this... Network transmission... battery management (including power saving on USB ports which is why people often recommend a High Performance power setting)... Really the WIFI cards fall into both categories of battery management and network since they consume a lot of battery power to run their radios. Display drivers can also cause problems. Lots of culprits.
 
Are you using a laptop? I can't remember.
 
So... download the program I gave you the link to... run it for 20 minutes and go to the drivers tab. Sort by the greatest latency and post your results to this thread.

I totally think that in 20 minutes of following directions from the geniuses in Cakewalk Support or some of the friendly posters on the forum, your problems will go away...
 
But you have to follow the directions.
 
Using the information learned from the LatencyMon.exe program, you may find that certain things needs to be disabled before making your recordings. For example, on my laptop, I disable Virus Scanning > Switch to High Performance Setting > Disable the Battery > Disable the Wifi Card.
 
Now, my laptop is old and you may not need to take these steps. Everyone's computer and peripheral drivers differ. That's why you run the LatencyMon to find out for YOU what YOU need to do.
 
Right this second tho, given the fact that you are running a RAIN computer, I think your problem is that 64 bit file write setting. At 24 bit 44.1, 8 mono tracks is about 4 GB per hour. At 64 bit, it will be near 11 GB per hour. Depending on your hard drives, you might be straining their ability to keep up in real time (this means... never get behind more than a couple of seconds worth).
 
Also, since your interface is only giving you data at 24 bit at the most, you are mostly writing 0s in your large files. It's just wasted space. 4 GB of music and 7 GB of 0s per hour when writing 8 mono 64 bit files....
 
See why to use 24 bit?
 

gswitz.... You have gone above and beyond the level of assistance one would expect. Thank you so much for taking the time to explain all of that.
 
I stream everything to an external hard drive, so maybe I've been pushing it way too hard?
 
My Pro Channel is currently working excellently...My heart is pounding! If you have fixed the issue that has plagued my creativity and passion for so many months...! My god.
 
I will have to try to over-load Sonar now - to test if it's worked. I won't know for a few days of testing whether it's fixed or not because this problem has gone away for a couple of days before, but then returned.
 
But your confidence makes me confident!
I will keep you posted....
 
 
 
 

So glad it's working Daylaa. Sorry if I was taking it in the wrong direction. Best of luck to you.

Please do keep us posted.  I've never been able to use X2 due to EXACTLY the same problems you describe.  And it's only sweeping the EQ in ProChannel that does it.  X1 also drops out intermittently while sweeping EQ on my system, but nothing like X2.  My PC is a new, desktop audio only system running an i5 processor with 16GB of RAM and running Win7 x64.
 
I've tried a new ATI graphics card, the on-board Intel graphics, different sound cards (Layla 3G PCI, Audiofire 2 Firewire, Presonus Firebox), farting about with buffers, moving card slots etc.  The problem shows up in the 32 and 64 bit versions of X2.  Nothing I've tried has fixed it.  The DPC latency checker shows a steady, low level of green bars with no spikes.  Indeed, Sonar runs smooth as silk as long as I don't touch the ProChannel.
 
As much as I'm tempted to upgrade to X3, I'm not forking out any more $$ until I verify the problem has gone away in an X3 demo.
 
I have my fingers doubly crossed that you can fix it.

OBHave,
 
If all you say is accurate...
Sweeping EQ Causes Drop Out
Nothing Else Causes Drop Out
 
Then you probably just need to increase you Buffer size...
Go To Preferences > Audio > Driver Settings
Click the Asio Panel Button (if you aren't using Asio, switch to Asio)
Keep your Sample Rate at 44100 or 48000 (don't try a double or quad rate like 88,200 or 176,400).
Set your Buffer Size to 2048 or whatever the biggest Sample Buffer offered by your interface is (not 128 or 256).
 
For the purpose of recording where you're tracking and want low latency, reduce this latency, but for general mixing, keep it high. You will find it easier to flip between screensets without dropouts if you keep the sample buffer at its maximum except when you are tracking.
 
I often flip the sample rate back and forth based on my current need. I bring it down for tracking. I usually start mixing without pushing it back up, but the first time I get a dropout do to a screenset switch (in your case EQ Sweep) I will jump back in and push it all the way up.
 
For mixing I don't care about a 2K sample buffer when there are 44.1 K samples per second. With a buffer of 2048, I still have a round trip of less than a tenth of a second at 48.
 
I hope this helps.
 
You could still probably benefit from using the LatencyMon.exe I give the link to in this thread (above). Laptops often have latency causing gremlins that are easy to disable, like the wireless card and the battery. Using the LatencyMon.exe will tell you WHAT the problem is. Then you just disable that device and you're all clear.
 
G

OBHave,
 
One more thing...
 
Recording excessively large files does INCREASE the work the FX do when processing the data.
 
This means that if you are saving your files as 64 Bit like Daylaa was, then when you apply EQ, the plugin is calculating the new value off the full 64 bit floats. This means that you have 24 significant bits followed by a lot of useless 0s. The plugin is still processing and doing the math on all those 0s. It's a huge waste of processing power.
 
Regards.

Thanks for the helpful hints gswitz.
 
My files are recorded to 24 bit, though the default in X2 was initally set at 32 if I recall correctly.
 
I'll try increasing the audio buffers to their max, but I'm pretty sure I've gone as high as 1024 buffers with a very simple project 2 or 3 tracks, and the EQ weirdness still didn't go away.
 
I'll give latencymon.exe a go.  I don't have a laptop - it's a standalone audio desktop PC, but latencymon should still work, right?