ew


@ the OP- try turning off hyperthreading in your BIOS.

ew

I have already tried that.  As well as core parking.
I was away on family, back now....getting into the swing of things again.

Report soon...

Just to add some interesting findings. 
My new i7-930 Win7 64 DAW has been running pretty well, with no glitches since I upgraded to an Echo Layla3G audio interface... but that's another story. 

I was pretty sure that I'd disabled core parking (ValueMax=ValueMin=0 in the registry tweak documented elsewhere), and according to Regedit, I have. I just checked. 

But looky-here:




That's SONAR 8.5.3 (32-bit version) running one of my large-ish projects, with the Windows 7 Resource Monitor utility in the foreground. You can see from SONAR's CPU meter in the big transport toolbar that one CPU core is doing most of the work (this is typical and I don't think represents a problem on its own). However, Resource Monitor seems to be telling me that 4 cores are parked!


So either I screwed up the Registry hack, or I forgot to completely power down (unlikely given the recent replacement of my PCI audio card!), or Resource Monitor is lying, or there is something else going on.


Can we trust Resource Monitor? Can anyone else who has successfully disabled core parking (as far as they know) verify that Resource Monitor is not showing parked cores?

@Sijel - No, not recently. However, since my last post I took a look at the Power Options and drilled down into the "Advanced Settings", and noticed the following:
 


Interesting... but this does not have anything to do with core parking.

Just to finish up this Core Parking sub-topic:
After following the instructions found here, my Power Options dialog has some new options:



Note the "core parking max/min cores" percentages. 

To completely disable core parking, we need to set "core parking min cores" to 100%, and "core parking max cores" to 0%. 

Important note: If you've applied the other registry tweaks to try disabling core parking, then you might need to undo them, and set ValueMax back to 64, before these new Power Option settings shown above become editable. This was my experience, anyway.)

After changing these settings as described above, I could see Resource Monitor change the display for the CPU cores to show that none of the cores were parked. And now, the SONAR test again:



... you know, I think the SONAR CPU meter is looking a little more balanced.

I'm not convinced people should be bothering with this Registry Tweak... theoretically, it should not produce a noticeable difference in performance if configured properly for High Performance

Sijel, I would agree with you, except that my impression is that it made a noticeable difference to the visual balance of the SONAR CPU meter, for my system at least.
Whether this actually makes a difference to how hard I can push the system before experiencing dropouts or glitches, I don't know. I wasn't having trouble before.

I think the take-away is this: 

1) If you're experiencing problems relating to dropouts or audio glitches that appear to be related to how hard SONAR is driving the system, then try disabling core parking. 
2) Make sure you actually *have* disabled core parking, because my experience suggests that some of the techniques published for it don't actually work on every system.

Here's hoping Benjamin gets some feedback from Cakewalk about his observations.

Sorry - this is a ridiculously long thread.  Which message # had the "first" reg fix and which message # had the second fix (that worked)?

I went back and peeked at my "old" Sonar install on my now-obsolete AMD dual core. It shows the two cores in Task Manager without any disabling of core parking under winxp64, so possibly this is something introduced in win7.

Core parking, I believe, only applies to systems with more than two cores/CPUs. It was introduced in Vista, I think.

Aw what a BUMMER! That is indeed the fix that I followed that worked for me.
I found two instances that needed changing to 0 from 64 and after that it all worked.
Doulbe check that when you did it you used the HEX option to change the values and not decimal. Although on reflection 0 is 0 regardless....

And you DID do a complete cold restart? LIke switch the `puter off and power down and all that good stuff?
You don`t need to take the mains plug out, but do make sure you are powered right down. Not a `restart` restart if you follow me.

stickman393


Just to finish up this Core Parking sub-topic:
After following the instructions found here, my Power Options dialog has some new options:



Note the "core parking max/min cores" percentages. 

To completely disable core parking, we need to set "core parking min cores" to 100%, and "core parking max cores" to 0%. 

Important note: If you've applied the other registry tweaks to try disabling core parking, then you might need to undo them, and set ValueMax back to 64, before these new Power Option settings shown above become editable. This was my experience, anyway.)

After changing these settings as described above, I could see Resource Monitor change the display for the CPU cores to show that none of the cores were parked. And now, the SONAR test again:



... you know, I think the SONAR CPU meter is looking a little more balanced.

Yup, I've tried all that.  All my cores are working fine, 100% across the board.  I have tried everything I can try.  This is very frustrating.  But I sincerely want to thank all of you guys for trying to help me (and others) with this issue.  I'll update as I find out anything else about this situation.

Ben C

Hey Ben,
I had stated previously in this thread that I was having similar dropout problems on a I7 860 with 8GB RAM. I couldn't ever get more than about 10-15 seconds into a song before it started dropping out, and then it would frequently increase to every 3-5 seconds. It gets to be maddening and extremely frustrating, I know. 
 
I'm ecstatic to report that I figured my problem out Friday morning after over a month of grueling diagnostic attempts. My system is now everything I had hoped.
 
What happened was I reached the point of completely removing Sonar 8.5 PE as well as my Focusrite drivers and doing a clean install. I was going through my Global settings to document them so I would remember what I had previously done, and I ran across my folder settings. I suddenly realized that my audio was mapped to my c-drive along with my project files (per project audio activated).  This was my second recent install of 8.5 and I hadn't mapped it correctly the second time. This was a complete oversight in that I always map audio to my secondary drive. I thought to myself - it can't be that simple, but it was. 
 
I opened what was one of the more problematic songs and saved it to my F-drive (audio drive) using per project audio folders, hit play, and it played perfectly. I spent the rest of the afternoon saving the rest of my songs this way and I haven't had a dropout since. I was on my system 4 hours last pm without a hiccup. Unbelievable. Having the Sonar program files, project and audio files on the same drive was causing the problem.
 
I don't know if you are set up in a similar manner, but I thought it was worth mentioning just in case. It's crazy how one setting like that can disrupt the whole system, especially on a screamin' machine.
 
Hope to help...
Vernon
 
FWIW - Upgrading to Win7 x64, Sonar 8.5, a new Focusrite interface, not to mention the new I7 computer and new components, all within a month or two, made diagnostics a b^tch!
 
BTW - I did contact Cake support, and they were very good. They suggested creating a 'ghost' audio track and arming 'echo input', stating that this can help with a known Windows 7 issue that causes dropouts. I guess an active track helps fool Windows to stay active itself. I tried this without luck, and was able to identify the problem .... finally!

I'll repeat. The issue is NOT Sonar.  You have messed up some configuration in your Sonar install.
This weekend, I was working on a 26 track project with at least 55 plugins installed. Not a glitch or issue the whole time - and that included recording guitar along with full track playback.
 
Have you called this in to CW Support yet?
Otherwise, all I can think is:  clear out all your Sonar config files (so Sonar doesn't use a "broken" file during your install) and re-install 8.5.3 from scratch.
 
Also, I noticed now that you added AlphaTrack... are you sure it's not contributing to problems?

Man i had the same problem.  I had dropouts, delays and the best thing you can do is to make a new partition, install XP and work there.
I find windows 7 is not very stable with Sonar X.

stickman393

I downloaded the demo of Gladiator last night. I'll install it and test tonight.
I figure I should be able to either reproduce Benjamin's results described here, or not. And that will give us more information.

With the demo, at least, I could not reproduce Benjamin's findings.  

I loaded up the Gladiator demo into Reaper, and made the CPU resource meters (both Reaper's and Windows') visible, and then played fast and lose with all 6 simultaneous voices, trying various patches all at ultra high quality.

Then I did the same in a SONAR project.

In neither case could I hear audio glitches, or experience dropouts, or anything negative in the SONAR case. I couldn't see any differences in the Windows CPU usage graphs. Of course, one can't compare the SONAR CPU meter with the equivalent display in Reaper (and I'm not sure I'm familiar enough with Reaper to know what to look for, anyway).

The important thing is that there was no noticeable difference.
  
Because I was using the DEMO version of Gladiator, I was limited to 6 voices, and Benjamin's test was done using all notes on a 66 key controller, so this is hardly a comparable test. I'm sure more simultaneous notes would exacerbate the differences between the two environments, and there's every chance my SONAR project would start exhibiting the symptoms that Ben described.
 
Despite this, I was hoping to see some obvious CPU spikes in the SONAR meter to match Ben's experience, but I don't really think I saw any. 

Alas, this is probably not a useful exercise.


Ben, if you can reproduce this with the Gladiator demo, or any demo or free VST that I can download, install, and test with, I'd be glad to do so.

I just did the same dumbass thing yesterdy night. started a new poject and was really struggling with partial dropouts, till I relaised I had reconfigured the system and forgotten to tell it to record audio to my D drive.
C drive is no slouch but apparently didnt like it much. 3 audio tracks and a couple reverb plugs plus an EQ and compressor and I was in trouble again.
I am beginning to suspect that I STILL have something else configured wrong. I`ll go away and check it out fron scratch...

PCs (uncluding Apples) are a pain when it comes to recording, right up to the point where you finally get  a useable system! (grin)

stickman393

stickman393

I downloaded the demo of Gladiator last night. I'll install it and test tonight.
I figure I should be able to either reproduce Benjamin's results described here, or not. And that will give us more information.

With the demo, at least, I could not reproduce Benjamin's findings.  

I loaded up the Gladiator demo into Reaper, and made the CPU resource meters (both Reaper's and Windows') visible, and then played fast and lose with all 6 simultaneous voices, trying various patches all at ultra high quality.

Then I did the same in a SONAR project.

In neither case could I hear audio glitches, or experience dropouts, or anything negative in the SONAR case. I couldn't see any differences in the Windows CPU usage graphs. Of course, one can't compare the SONAR CPU meter with the equivalent display in Reaper (and I'm not sure I'm familiar enough with Reaper to know what to look for, anyway).

The important thing is that there was no noticeable difference.
 
Because I was using the DEMO version of Gladiator, I was limited to 6 voices, and Benjamin's test was done using all notes on a 66 key controller, so this is hardly a comparable test. I'm sure more simultaneous notes would exacerbate the differences between the two environments, and there's every chance my SONAR project would start exhibiting the symptoms that Ben described.

Despite this, I was hoping to see some obvious CPU spikes in the SONAR meter to match Ben's experience, but I don't really think I saw any. 

Alas, this is probably not a useful exercise.


Ben, if you can reproduce this with the Gladiator demo, or any demo or free VST that I can download, install, and test with, I'd be glad to do so.

Hello :) Thank you for your attempt, but sadly, it seems that only when you max out polyphony in the VSTi's I'm working with, then you see the problems.  SONAR has no issues at all on my end, when you use "simple" light VSTi (low voice count etc).  But try a project with Absynth, Rhino, Gladiator, Rapture, and Zebra, each synth have between 32 and 256 voices each, and SONAR crumbles, period.  I am not interested in having this thread turn into a flame fest - everyone has a right to their opinions.  And I absolutely respect that - don't confuse that please.  I am simply saying, SONAR is the problem.  It's a conflict/CPU/issue of some kind.  Not my PC.  Doesn't matter if I defrag, clean my cookies, reinstall Sound Forge, it's just a SONAR issue - of some kind.  CPU usage is out of control, within SONAR, and within other DAWs and in my Windows Resource Monitor - all is well.
I'll repeat what I've said all along - I truly appreciate all the help guys! :)  I hope that SONAR 9 perhaps is more CPU-efficient with regards to the new i7's, or "CPU intensive" synths that are popular these days.

Hope you all have a safe/happy labor day weekend!

Ben