Problem with the SONAR CPU meter please...?

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

ew

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...

Damn! Was so pleased with my stuff working I felt sure we had collectively found the answer.
Fingers crossed, mate.

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?

Interesting pic!  I will need to recheck my parking when I get to my Sonar.
Just curious - have you changed any desktop or power management settings recently?

@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.

The truth is, this is off-topic as far as Benjamin (OP) is concerned. If Reaper is running a certain workload without problems, but SONAR is not, then it's not Core Parking that is the problem.

Additionally, my understanding is that if you are experiencing audio glitching, *and* you have core parking enabled, then it may be that disabling the core parking will eliminate the glitches - if they are somehow due to some kind of thread scheduling conflict or whatever. 

I don't think that the core parking evident on my system is causing a detrimental effect on my SONAR performance, at least not from an audible perspective.

On the other hand, the lop-sided CPU meter in SONAR has *always* bothered me.

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.

Good work and great documentation of your results - very plain to see!
 
Here is a Microsoft document that provides more details on the registry entries you manipulated:
http://download.microsoft.com/download/3/0/2/3027D574-C433-412A-A8B6-5E0A75D5B237/ProcPowerMgmtWin7.docx
 
The table on page 34 defines the "core parking min cores" (the bold emphasis is mine):
Description
The minimum percentage of logical processors (in terms of all logical processors that are enabled on the system) that can be placed in the unparked state at any given time. For example, on a system with 16 logical processors, configuring the value of this setting to 25% ensures that at least 4 logical processors are always in the unparked state. The Core Parking algorithm is disabled if the value of this setting is not less than the value of the Processor Performance Core Parking Maximum Cores setting.
GUID  0cc5b647-c1df-4637-891a-dec35c318583
PowerCfg Alias  Not applicable
Minimum Value  0
Maximum Value  100
Label Percentage (%)
Hidden Yes   

You've set this value to 100% (which is more than the Max val), so Core Parking is Disabled.
According to the table above, you should be able to set Min to anything greater than Max to disable Core Parking.
 
Now that we've ellucidated the science, 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.  Afterall, if the OS thinks it doesn't need the extra cores to do its task scheduling and the unparked CPUs are not pegged, who are we to think the OS will do better by "unparking" all the remaining CPUs?
 
So, I wonder:  Would I just be creating more heat inside my DAW and making the air fans or water cooling work harder -which in turn produces more noise?   As Homer Simpson would say,  D'OH!!

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.

Interestingly, 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.
Not sure but it all helps narrow in on the OP`s problem.

I`ll have a look at what Sonar reports internally re core parking, but can I reiterate that I tried the first "registry fix" in this thread unsuccessfully and it wasnt till I did the second one that all was well.
Probably me doing the first one ineptly, but worth a check. 

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

The first technique I encountered in my research did not successfully disable core parking in my system. I had to reverse the registry change in order for the second technique to work.

I describe my experiences in detail in this message earlier in this thread.



(ivanSC, please let us know if you followed a different set of techniques.)

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.

@Ivansc: yes, as far as I know, I did the tweak that you said had "all six cores rocking"!  (I'm jealous!)
 
This is what I did:
 
How to properly  disable "Core Parking"

- Go to Regedit 
  
- Find this key:-  " 0cc5b647-c1df-4637-891a-dec35c318583 " 
  
- Within this key, there is a value called:  " ValueMax " 
  
- This value represents the % number of cores the system will park - the default 100%  ie:  all Cores are potentially park-able 
  
- Change the value from 64 to 0 so the " ValueMin "  and  " ValueMax " are both zero 
  
- You will have to find the key a few times and repeat the process for each time it is found - the number of instances will depend on the number of power profiles in your system  [  in my DAW it was only found twice ] 
  
- Do a full shutdown and power-off and cold-re-start 
 

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.

As you can see from the above, sticky, I used what you described as the first method which was the second one I came across!
 
Confusing, eh?
 
And I`d like to confirm that a few days after, it is all still working so well I could poop myself for joy.
 
 

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

I just tried SONAR 8.5.3 - with an empty new project.  Just one synth loaded now.  Gladiator.  Preset: PAD "PA AnalogFat MF". 256 voices, ultra quality.

I played, with sustain pedal down, every single key on my 66 key MIDI controller pedal down....

SONAR dropped out, and I had to restart the engine after 4 seconds.  I used my forearms to cluster the keys, in order to max out polyphony asap.

Same test in Reaper.  I could use forearm smash after smash, pedal down, nothing but smooth sounds.  No glitching, freezes, or cracks/pops.  CPU stayed at a meager 8% for 45 seconds, and finally after pounding and pounding I finally heard one glitch/pop in Reaper.  So I stopped. Real Time CPU was about 30% or so, but it did peak once to about 80% (after that whole time).  The 'actual' CPU of course, of my PC, and Reaper's "Total CPU" was 4% even through the glitching.

Now, practically - of course I'd never compose like this.  But, SONAR seems to not even be able to handle a real-world example, yet Reaper can handle 90% of an impractical and unlikely synth arrangement/polyphony/pedal style overflow.    I do often use clusters and such, and SONAR can't seem to handle even the first 3 or 4 "clusters" at those settings.  Yet Reaper could withstand so much more, regardless of the obvious lack of "Real World" application you could argue.

I'll let you know if I find out anything else.  Thanks everyone.  I really appreciate the help.

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!

Under record options under the transport menu see if arm for recording while playback is checked if so uncheck it and see what that does.. Also in your options audio dialog you have no record timing master checked. Mine is set to my audio device as is the playback timing master. You also have no inputs selected in the driver tab.

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?

I downloaded the demo of Goliath 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.

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.

to OP:

I agree with you that "sonar" is the common factor always in your problems. With this in mind, try to pinpoint your problem by thinking which Sonar features are not there in other DAW software.

For example, does Reaper have a 64 bit "double precision" engine? Try disabling that in Sonar, see what happens! ;)

*just a suggestion, I thoroughly read all messages in this thread, my apologies if this has already been mentioned, tried and I didnt notice it*


*edited for typo*

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.

Alas, this is probably not a usual exercise.

I think your work is very useful since it shows Sonar can handle heavy loads when properly configured.
I've tried to replicate the OP's issue with Dim Pro with Trillian and Pentagon and using 3-4 plugins on each output track and I just don't see a problem. (Thank goodness for me but not for the OP).
 
I've been noticing that people that use other DAWs seem to have more problems than people that only run Sonar.  I suspect there may be inter-DAW conflicts or that they are using habits/settings/tricks/tips from other DAWs that aren't holding up well with Sonar.  Just a thesis at this point...
 

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)

Sijel


I'll repeat. The issue is NOT Sonar.  You have messed up some configuration in your Sonar install.
 
Also, I noticed now that you added AlphaTrack... are you sure it's not contributing to problems?

I disagree.  It is SONAR, I've ruled everything else out.  I've reinstalled my OS, SONAR, apps/drivers, etc. - it doesn't matter.  Alphatrack or not.
SONAR has a conflict, or whatever you'd like to call it.  Other DAWs seem to handle my VSTi load just fine.  I won't rehash my findings.  I've messed nothing up.

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

For those who are trying to wrap their heads around this thread, try to go back and follow my findings - it does make sense, imo.  With modern CPU heavy synths, even in an i7 quad machine, SONAR simply cannot make efficient use of its CPU meter - and thus drop outs occur.  I could make you screencasts till the cows come home.  I already tried that earlier in the thread.

Reaper is just one example of how I expected to run my synths on my new PC.  The difference is night and day, not just "a little" better.  SONAR just can't keep up.  I am a MIDI heavy composer, and I expect to be able to use my synths in a powerful manner - just like Reaper will allow me.
For now, I am ReWiring Reaper -> SONAR 8.5 and guess what?  It's still working, this whole time.  It's a temp fix, but...hey.  It works.  Obviously hosting these synths in SONAR 8.5 is the problem.  I didn't mess anything up.  I know PCs.

So, for those having similar issues, I hear your pain. I built my new mega PC, and this set back kills me.  But ReWire Reaper into SONAR, host the synths in Reaper, and you'll be golden.  SONAR is barely even hiccuping.  :)  So, the proof is in the pudding.

Have a good one guys!



I'll check out SONAR 9, and be patient, and we'll see if that fixes anything.  I'm sure it will :) I have faith in the guys @ Cakewalk!

Sijel

Alas, this is probably not a usual exercise.

I think your work is very useful since it shows Sonar can handle heavy loads when properly configured.
I've tried to replicate the OP's issue with Dim Pro with Trillian and Pentagon and using 3-4 plugins on each output track and I just don't see a problem. (Thank goodness for me but not for the OP).
 
I've been noticing that people that use other DAWs seem to have more problems than people that only run Sonar.  I suspect there may be inter-DAW conflicts or that they are using habits/settings/tricks/tips from other DAWs that aren't holding up well with Sonar.  Just a thesis at this point...
 

I don't believe other DAWs installed on a machine would affect SONAR's internal CPU meter in such a way, imo.  And with respect, Pentagon is a lightweight CPU synth compared to the ones I listed.  And Trillian is a sample based instrument, RAM-wise it's very intensive.  I have had no disk errors at all in SONAR, streaming/drop outs or otherwise.  Also, DimPro (as I've alluded to before in this thread) is a plug that really only adds to the stress of my project's load, it's not the plug that puts SONAR over the top intro dropout mode, it's just a headache when used with other CPU intensive plugs.

I use Stylus RMX and Trillian and the issues are nowhere NEAR what I've been describing, under most normal scenarios.  That again enforces my belief that it's a SONAR/CPU issue, not a disk streaming/RAM/memory problem.  That's not my issue with SONAR at the moment

I am glad you are not having problems :)  I am jealous my friend...

One final thought before bed:

Many many people (not just in this thread, but on other forums and in the field I've heard) have complained about SONAR dropping out, or being inefficient with synths/plugs, CPU-wise...etc

I may have a unique issue, per say, but I'm willing to be we are all somehow, slightly at least, connected with our problems.  It's far too often, and across the board to be ignored.

I love SONAR, I love Cakewalk products.  I have no intention of leaving them, but I do hope they can make some adjustments.  Maybe people are not posting these negative reactions, or frustrating issues with SONAR because they fear the response?  Guilty before innocent, type stuff.

I'm not attacking SONAR, Cakewalk, or anyone here.  I'm just curious.  This is my first problem with SONAR in almost a decade.  I'm obviously not a guy who just wants to ****.  So, please give me some credit.  I hope you all can see that.  :) 

That said, I have no issues temporarily ReWiring Reaper into SONAR, so I don't lose my job here.  But, it's pretty obvious that if ReWiring these synths in Reaper -> SONAR works, and loading the same plugs directly in SONAR do not (i.e. the CPU spikes), then clearly - I'm on to something.

Hope this helps others.  Thanks again for all your help everyone, I truly do appreciate it.  Just try to understand that I am stressed about this, and can't afford much more downtime or else I may lose some money in the long run, in my position.

Good night all! :)

Benjamin - I am getting to the point where I suspect it will just be easier to switch permanently to Reaper, which is still running flawlessly under the same circs that is getting pops clicks dropouts and lord knows what else in Sonar.

I am putting nowhere near the load on my system that you are and yet I still have this unaccountable performance difference between Sonar and Reaper.
Oh, and I even dropped down to using the 32 bit versions of Reaper and Sonar to see if it made any difference.
It didnt.
Frankly, I am getting tired of being forced to become a software engineer when all I want to do is make music.

Sonar used to be pretty decent up to and including 6 prod, but I am really regretting buying the upgrade to 8.5.3 now.

Sijel

 
 
I've been noticing that people that use other DAWs seem to have more problems than people that only run Sonar.  I suspect there may be inter-DAW conflicts or that they are using habits/settings/tricks/tips from other DAWs that aren't holding up well with Sonar.  Just a thesis at this point...
 
 
 
Well I for one had a clean win7/64 install with JUST Sonar 8 & then 8.5 on it.  I only installed Reaper on the same machine after seeing it run rings round the AMD Hex Core box with 4gb, when I used it on my old AMD dual core with 2gb.
And as far as I know I set Sonar up the same as I did on the old machine - I have several years with Sonar and very little experience of Reaper.  

ivanSC


Benjamin - I am getting to the point where I suspect it will just be easier to switch permanently to Reaper, which is still running flawlessly under the same circs that is getting pops clicks dropouts and lord knows what else in Sonar.

I am putting nowhere near the load on my system that you are and yet I still have this unaccountable performance difference between Sonar and Reaper.
Oh, and I even dropped down to using the 32 bit versions of Reaper and Sonar to see if it made any difference.
It didnt.
Frankly, I am getting tired of being forced to become a software engineer when all I want to do is make music.

Sonar used to be pretty decent up to and including 6 prod, but I am really regretting buying the upgrade to 8.5.3 now.

Well, honestly - personally, I'm not ready to give up on SONAR yet.  I have used it for so long, and have enjoyed a successful career as a composer/arranger (thanks to SONAR), and I am optimistic I can get to the bottom of this.  With the help of the awesome people here on the forums, and Cake support, we'll figure it out :)
I may enjoy Reaper's approach to DAWs, but I truly love the power and flow of SONAR - not to mention the GUI.

I'm sorry to hear you are having similar problems as I have.  There are many of out there, if that helps you at all.  I love the plugs that come with SONAR - truly powerful, professional results every time.  It's just an issue of CPU/synths these days.

Now that I have more free time (work has been brutal, end of summer) I'll just contact Cake and see what they suggest.

Thanks again everyone, I appreciate the help!

We all love SONAR here, but there is also a chance that perhaps it does lack is some areas....doesn't mean it's useless, just needs improvement.  That's all.

Let's make SONAR even better! ;)

DID anyone having these issues tried my suggestion of switching the "64bit double precision engine" off?

Yes. I tried with it switched on and off. no difference on my system.

I was really down yesterday & feel a little more er optimistic today.
But I still spent all afternoon trying to record SOMEthing without seeing massive cpu loads and pops & clicks. I sey my buffer down to 512 and I am STILL getting problems. Even my old dual core can do better than that running an identical project, so I am now beginning tosuspect that it is a combination of win 7 the 6 core and sonar.
Going to reinstall 6 pro tonight and have another try with the same audio imported into 6 and using the same plugs, such few as they are.
Throws me completely that such a relatively light cpu load shoul dgive me all these problems.  Been playing back stuff in various other programs including watching  DVD
just to be sure and no problems anywhere else.

Boy I have reached the point that I no longer know where to look next.
Checked the Performance manager and all 6 cores are trotting along nicely at an average load of around 10-12%.  Sonar is peaking at 50%, which shoul be acceptable, but unless I run the buffer way up around 512 it is unusable with just a track of double bass with a cake compressor plug, an acoustic rhythm guitar with a cake comp and the basic cake reverb, then a second guitar track with just compression.
By the time I got to tracking the second guitar I had already been forced to up the buffer to 256 and the third track was still popping and hiccuping like crazy.
This just does not make sense, especilly since the Reaper project I tracked right after used a VST plugin for guitar processor(IK Multimedia one) as well as all the other stuff. 
Started tracking vox on that one and STILL had the buffer set to 32, which apparently equates to 0.7ms of latency going in.  I can live with that, believe me!
This is the sort of performance I had anticipated from my new system all along.

IvanSC and Ben, I hear you.  I'm at my wits' end, too.  I thought that after uninstalling all the junkware on my new dedicated Sony Vaio I7 quadcore, I'd be in the clear.  And indeed, I got a couple of hours' smooth Sonaring after my last (optimistic) post.  But today, playing a song with my favorite collaborator (my 7-year-old daughter), the f-ing thing dropped out right at the second chorus and we had to stop, reset, restart Sonar, etc. etc. and at that point, neither of us was that into it anymore. 

I'm not much of a software engineer, and I don't want to become one.  I just want to make music -- that, for me, is hard enough!  I've been a longtime Cakewalk user (back to whatever version was available in the Windows 3 era) and there has always been a degree of tweaking involved, but for the first time, the angst of all that tweaking isn't being outstripped by the wonder and enjoyment of what this program can do.  In other words, I may finally be losing this battle. 

My last ditch attempt will be to try a new audio interface (my Presonus Firebox drivers have never been particularly stable, and it's conceivable that they could be the source of all of this).  That'll come with some lite DAW software, I'm sure.  Then I can A/B it against Sonar if necessary, and if it works glitch-free, I'll have my solution ...

What drives me nuts is that I built my own machine from scratch, it has a minimal Win7 64 OS install and has pretty much nothing apart from Adobe reader and word for windoze on it. Oh, and Sonar (and more recently, Reaper)
It is the most modern mobo I could find at the time and all drivers are up to date. The RME pci card I am using for audio is supposedly one of the most reliable cards out there with good, up to date reliable drivers.
The machine flies with anything other than Sonar, so it is getting harder and harder to draw any other conclusion but tha Sonar is the culprit, for whatever reason.

So now I am left with a choice of sticking with my now over $1,000 software investment and not making any music or jumping ship to something I do not know very well and STILL not making any music.
Devil - say hello to Deep Blue Sea

The only thing I can say is because you all are running into the same problem it would be perhaps a good idea to compare systems and what you have in common. It could be a MB or some device you have in your system that is causing this problem.

Joghn - since the three of us reporting problems are not all using AMD 6 cores as I am, I doubt this is cpu or mobo related.And apart from the ram there isnt really all that much left inside the average pc that could influence this sort of behaviour.

I am good at hardware troubleshooting (build and repair them for others ) and thought I was reasonably competent on software and firmware but this has me beat.
I cant even quantify it to the point where I could put in a solid support ticket! 

Something is causing this. I do believe it is a very difficult issue as can be seen by the length of this thread and non ability to fix this.

There has to be a common denominator that would give some clue. Perhaps its some software that you each have on your system. I don't know clearly but because you all seem to unfortunately share the problem it would seem some what prudent to compare notes in a systematic way.

I am at a loss as to what is causing this. But I do think there is something you all have in common that is the cause.

I do hope that you do find an answer.

I am also sorry that I have nothing else to offer.   

benjamincharles


For those who are trying to wrap their heads around this thread, try to go back and follow my findings - it does make sense, imo.  With modern CPU heavy synths, even in an i7 quad machine, SONAR simply cannot make efficient use of its CPU meter - and thus drop outs occur.  I could make you screencasts till the cows come home.  I already tried that earlier in the thread.

Reaper is just one example of how I expected to run my synths on my new PC.  The difference is night and day, not just "a little" better.  SONAR just can't keep up.  I am a MIDI heavy composer, and I expect to be able to use my synths in a powerful manner -

You telling us you use a lot of software synths and SONAR can't keep up with power use of maximum of 3GB RAM that Windows 7 32bit use...?

Please, I say again ---->you still you use x32bit OS and SONAR x32?
Please,  upgrade to Windows 7 x64bit and SONAR x64bit if you serious user and then tell us if you still have the same problem? I can tell right now that you won't...



Its like you have a modern LED 42# Full HD-TV and watch movies in black and white from the mid 1940. Then you complain about bad picture quality and there are no colors in the movie either from 1946. You then ask yourself what's the big deal about HD-TV? I don't see any benefits?



Best Regards
Freddie

Take a look...--->  http://forum.cakewalk.com/tm.aspx?m=2086193

I'm running Windows 7/64 Professional and 64-bit Sonar, so that's not the issue for me, at least. 

Ivan/Ben, I'm happy to follow up on John's suggestion, but I'm not sure how.  Here's what I know of my system:

- I have a Sony i7 quad core, 4MB RAM, Win7/64 Professional, Sonar 8.5.3 Producer Edition 64-bit.  My default sampling rate is 48Khz, 24-bit.
- My audio interface is a Presonus Firebox with the latest Windows 7 ASIO drivers, which set themselves at 6ms latency (I'll note that my mobo uses the Ricoh firewire chipset, which is supposedly a red flag ... and it's why I'll try a non-FW interface before giving up on Sonar altogether).  Just for kicks I'm going to bump up that latency (which, I see, is lower than the actual reported latency in the Audio Options menu).   
- I have disabled all services except MS/Windows services, turned off wifi and all on-board audio devices. 
- I have optimized W7 for best performance, disabled Windows Search and Superfetch, and turned the Aero theme and ClearType back on (leaving them off didn't matter, and I like both a lot). 
- I have uninstalled all the pre-installed junkware I can find in the programs list (Norton, Quickbooks, etc.)
- I have installed only Sonar with all the extras, Adobe reader and the Firebox driver.  I turn on wifi to check for software updates, install them and then turn it back off. 
- I have not repartitioned anything. 
- I have done the disable core parking registry fix IvanSC discussed above.
- I had a Matrox dual-monitor setup but I got one large monitor and unistalled the Matrox system. 

That's it -- no other software, hardware, etc. has sullied this system.  Detailed specs on my computer can be found here:

http://www.pcconnectionexpress.com/IPA/Shop/Product/Detail.htm?sku=10948065&cac=Result

I suppose we're looking for a common thread ... would be very interesting to see if there is one.  The ONLY thing I can even imagine is causing my problem is the Firewire interface ...

Take no notice of Freddy - he just reads anything that seems like it might smack of un-64 bittedness and goes off on one.
Calm down, Freddy - I for one am using win7 64 bit and have tried both Sonar and Reaper 64 bit. Reaper works fine. Sonar doesnt. Happy?

ivanSC


Take no notice of Freddy - he just reads anything that seems like it might smack of un-64 bittedness and goes off on one.
Calm down, Freddy - I for one am using win7 64 bit and have tried both Sonar and Reaper 64 bit. Reaper works fine. Sonar doesnt. Happy?

Freddy:
How does your frequent 64bit remarks help our situations?  I'm just curious.

lol - it reminds me of that Chris Rock sketch about his father and tussin:
----
You had to be damn near dead
to see the doctor.

You had to be way past Robitussin.

That's all we had
when l was a kid: Robitussin.

No matter what you got,
Robitussin better handle it.

-''Daddy, l got asthma.''
-''Robitussin.''

-''l got cancer.''
-''Robitussin.''

l broke my leg,
Daddy poured Robitussin on it.

----------

It's like going 64bit is a cure all. Just go 64bit, and it will heal all.

I am new to these forums, so I may be wrong (please correct me if I am) - but what's the deal with the constant 64bit pitching?
Does it really ever help the threads that you post them in, Freddy?

Moving on though - to other poster here - I believe SONAR is the biggest common thread that we all share.  I built my machine too, piece by piece.  I use CPU intensive synths, and simply put the only DAW I've encountered issues with them is SONAR.  Reaper, FL Studio, MiniHost, all work fine.  Same PC.  Somehow, someway, SONAR is indeed responsible. 

I feel like a broken record :( Sorry guy...I'll just stop the bleeding.

I truly appreciate your help everyone.

Thanks -

I built my machine too, piece by piece.

Seems like that is a common theme too.
 
I've had near flawless operation with my Alienware box.  Your thread has seriously convinced me that the extra $200 it cost over building it myself from parts was $$ very well spent!

I don't think it's a homebuilt issue: My computer is a brand-new Sony Vaio that I haven't touched other than to turn it on.  (My last computer, which was homebuilt, ran many versions of Sonar with no problems!!)

Same problem, though.  I do notice that my Firebox is frequently falling out of sync (the blue light turns red momentarily), and that seems to precipitate the Sonar dropouts.  I also get a strange error message in Sonar about it losing the Firebox WDM drivers, which is particularly strange as I'm using the ASIO drivers ...

Next step (in the next day or two) is to yank the Firebox and try Sonar with the Vaio's on-board audio interface.  I have no doubt my recording quality will suffer (though I can still use the Firebox pres, I suppose -- and maybe even its SPDIF out) ... but I'd trade that for a Sonar installation I can actually use ...

I assure you it's nothing to do with the barebones construction, with respect.  Sorry Sijel.

I just loaded one instance of Octopus in Reaper, and play around with a 24 voice pad.  The RT (Real Time) latency is about 40%, but "CPU" is only around 7%.

That proves that SONAR is indeed display the "Real Time" ASIO/CPU (40%)....and that's why it stutters and drops out.  If only there was a way for SONAR to follow Reaper's path and allow it to "see" and use the actual TOTAL CPU, vs. "RT CPU" (real time).   SONAR keeps insisting on abiding by the RT CPU....it's very frustrating.  I don't have to have the CPU display different, I don't care if it's always flickering, I just would like it to not drop out in the situation I uploaded below in the image.  That exactly project/instance of one VSTi, caused SONAR to drop out.  24 voice polyphony, one Octopus VSTi instance.  It is SONAR, not my NewEgg PC.

That's all it would take to fix this problem.  If you want a video, I'd be happy to screencast one.



See?  Reaper is guided by the actual CPU, not RT/Real Time CPU (which SONAR is guided by).  That's why I get constant drop outs in SONAR.  I wish the SONAR CPU was calibrated differently, and measured differently :(

The above image caused major drop outs in SONAR, yet smooth sailing in Reaper, and MiniHost.  It's a SONAR issue.  Somehow related to how SONAR interprets CPU usage. 

No absolutely not.   If all you want is for the CPU meters to be the same in Reaper and Sonar then that will mean nothing as far as what impact it has on how Sonar can run; what load Sonar sees as critical for it it to do its thing.

If you are saying that Reaper can handle a greater load that is a fair statement. It really makes no difference what the meters  say as long as they are consistent with the program.

As I said in a early post CW has documented how its meters work and I for one understand that. I also can relate what they say to judge how much CPU room I have on a project.

If you have been on this thread going on about this as how Reaper can handle more stuff then Sonar then unless you are really prevented from using Sonar in your daily work its no real issue.

I am just fine with Sonar and what I do and how my projects are setup. I have no need what so ever of going to another DAW because I can't do the things that need to be done.

This is very different from the others that seem to have a real problem in getting anything done due to way too much CPU usage. An abnormal situation that I and I am sure most do not have.

You need to clarify what is it you have a problem with. And if its some apparent roadblock for you making music on your Sonar DAW and simply a comparison of Sonar to Reaper.

John -

SONAR can't seem to handle the CPU load from the VSTi synths I'm trying to use on a daily basis.  This in turn is hurting my workload as a composer/arranger.  It does hurt me John.  That's why I started this thread.  I only chose to ReWire Reaper into SONAR, as a temp fix, in order to load the synths I need to work with.  When I load any of the CPU-heavy synths in Reaper, and ReWire into SONAR - all is well.  SONAR's CPU meter barely registers.  That's great.  When I load those synths natively in SONAR, and only have SONAR open for my project, I get crackles/pops/and dropouts.  It's the way it goes.  Loading synths directly in SONAR is the problem.  Not the CPU visually, it's how it "reads" and reports the CPU usage.  I have zero problems with SONAR as far as recording audio, only when you use VSTi synths does SONAR fail.

I agree with you on the CPU issue - but I've said that before, I thought. I don't care what the CPU in shows visually - as long as it allows me to work with the synths, then that's fine :)  When SONAR "does its thing", that's the problem.  It's not doing it "right".  It's reporting the CPU fine, as you said - and I've always agreed with that John.  But it's not distributing the CPU load as other apps do, and that is killing me.  Whatever SONAR is doing with the CPU under the hood, that's the issue.  Look at other examples I've given please.

John: right now, Reaper, FL Studio, and MiniHost all "report" the same CPU as SONAR, % wise - yet SONAR is the only one of them that actually has dropouts and pops due to the CPU meter peaking. So, I'm sorry if I had not been clear in earlier posts.  But that's all I really need help with.  Getting SONAR to stop dropping out when other applications, under the exact same setup, do not fail - is my main priority. It's killing my business.  Without ReWiring Reaper at this time, my work would suffer tremendously.  But, as I've said many times, I am loyal to SONAR and am trying to work this out.  But, for now - I need a temp fix.  Thus, Reaper via ReWire. 

I am like the others.  CPU is getting in the way of literally every project I work on.  I just happen to be a VSTi/MIDI heavy composer-user.  I'm happy that you are not having problems like I am, and others are.  But the bottom line is, I can't get any work done without ReWiring in my synths.

It's that simple.  SONAR does not allow me to load the synths in question because the CPU meter locks up and drops out.  Yet, when I ReWire those same synths into SONAR, hosting the VSTi in Reaper -> SONAR, all is well.  So the issue lies in loading these synths in SONAR.  I'm not sure how much clearer I can get.  This thread is quite long, and I appreciate your patience.  But what am I doing wrong here? I've stated the same thing over and over, nothing's changed at all on my end.  I don't really feel its fair to shoot the messenger here.

John:  what is your opinion on the cause?  Reaper, MiniHost, and FL Studio can host the synths and have no dropouts.  SONAR drops out and pops/clicks with the same project.  Same ASIO buffer settings, same everything.  It's a SONAR issue.  Yet, if the synths are hosted and loaded in Reaper, and ReWired into SONAR, SONAR works flawlessly and the CPU does not spike AT ALL.  Same exact synths, setup, settings, ASIO, everything.  But SONAR drops out instantly almost.  But those same synths, same everything - but only difference in they are "hosted" (i.e. loaded) in another app and sent into SONAR, and SONAR is flawless.  I even tried raising my buffer (ASIO) to the higest setting, with insane latency.  Made no difference.  SONAR still could not handle the CPU load efficiently.  Dropouts galore.  I'm not bad mouthing SONAR, I keep feeling like many here are against me - but I just was hoping for some help to fix my SONAR so I could go back to using it (without having to ReWire stuff in).  SONAR is not perfect.  But it's close :)
Many share similar issues as I do.  Yet, each circumstances are different enough to merit some concern, imo.

What do you think of that? I'm not sure how it could be anything else but SONAR at this point. 

Thanks for your help. I hope that answers your questions. :)

To respond to your post directly John: Reaper can handle a significantly higher load than SONAR.  A fair statement, indeed my friend.  Other than that, I've been a die hard SONAR fan for years, and it's the most powerful DAW ever made.  Period. :)  I just want it to work for me :(

What do you think of that?

I think you should call Cakewalk tech support. As it appears you've pretty much exhausted the collective wisdom - and maybe the patience - of the forum at this point.

John requested that I clarify my problems - and so I did.  That is why I continued my previous post.  After seeing all the awesome support from the helpful people who have posted here in my thread, I felt that answering his question was the least I could do to show my appreciation.

Thanks!

And the people here have been more than patient and helpful.  I've thanked them countless times throughout this thread.

:)

I've thanked them countless times throughout this thread.

Yes, sorry if my comment came off sounding a tad brusque. But I meant it seriously; I think this might be a job for the "Pros".


The only part of your experience I have sometimes experienced is SONAR is maxing out its CPU meters, and starting to pop and crackle, while Windows (Win 7 x64 in my case) reports maybe 30% CPU utilization. But I don't worry about it, because it takes a much heavier plug-in load that I never encounter in a real project (mine are all pretty light due in part to heavier dependence on hardware synths) to get it to that point. And that severe disagreement between SONAR and Windows on what the CPU load is the exception.

As a reference point, you might want to run one of SONAR's demo projects like Justin Lassen's "Dark European Space Adventures". This project idles and plays with SONAR's CPU meters bouncing around in the 20-40% range on my Q9550-based system with a 96-sample ASIO buffer. Windows averages about the same, but with greater variation, probably because it is looking at instantaneous values, while SONAR is measuring how much time it took vs. how much was available to process a 2ms audio buffer.


In any case, it might help to get a grip on things if you use a reference project that everyone has access to.

Just my 2¢....

Bejamin, I want to thank you (and everyone who's tried to help) for your patience during this month-long process. I read every one of these 178 posts, and you've all been exceedingly patient, polite and professional--particularly at a time when a man's job could depend upon getting this issue resolved.

I understand others are having a similar problem with SONAR dropping out, but has anyone resolved the issue of Benjamin's disk usage being at 0%? For those of you who are having similar problems, is your disk usage at 0%? Can you reproduce this?

And Benjamin, I understand you've backed up your drive, "wiped it" and put everything back, but have you actually tried wiping your drive re-installing Windows, SONAR, your audio drivers--and nothing else (not even Reaper)? This would be a truly "clean" system. (If you're up to it, you could create a dual-boot scenario for this test.) Of course, you'll still have to disable all unnecessary startup items and services, but Black Viper's Website can help you with that. If all you've done so far is restore what you've backed up, then you've put the same (potentially) corrupt installation of Windows/SONAR back onto the hard drive.

Please forgive me if you've already tried this; I didn't see it mentioned. I just want to be sure you're not putting the same software back in the same configuration. I'm wondering if there's something particular about this Windows/SONAR installation that's bothering SONAR and not Reaper. A truly clean install will also force the gang at Cakewalk to focus on SONAR and your configuration, instead of trying to blame something else. (I'm not saying they would try this, but I've been doing tech support for 18 years, and the first thing I usually see corporate tech support do is "blame the other guy".)

FWIW, I wouldn't hope this has been fixed in SONAR 9--especially since no one knows what's wrong (or what SONAR 9 "improves"). Also, Cakewalk has a terrible habit of removing features between versions, so unless you're feeling particularly lucky, I wouldn't risk playing "upgrade roulette".

I understand others are having a similar problem with SONAR dropping out, but has anyone resolved the issue of Benjamin's disk usage being at 0%? For those of you who are having similar problems, is your disk usage at 0%? Can you reproduce this?

If his test project is pure MIDI and soft synths with no audio and no sample-streaming synths, his disk usage could easily stay at 0%. The project I mentioned above will show 00% most of the time with an occasional excursion to an exhilarating 01%.