I just had dinner, and I got to thinking.  First off, I want to say a huge thank you to all who have helped me in this thread :) That's one of the reasons why I love Cakewalk/SONAR.  So, thank you.   Next, please allow me to summorize my situation.

Sonar's CPU measures audio buffers/samples (not straight "Task Manager" CPU load).
Reaper's CPU measures approx. what the "Task Manager" CPU load is at any given time (including RAM).

Knowing this, I have a few concerns and concluding questions - please.

1) I wish SONAR's CPU actually measured just that: actual CPU usage.  If that was the case, my SONAR CPU would literally never be above 30-40% - and that would be a huge 20+ track/VSTi project with processing.  Reaper's DAW CPU meter shows "Task Manager" style CPU readings: so in theory, it would take a heck of a lot of tracks/VSTi's to cause "dropouts" in Reaper.  Because it follows true CPU.  Work with me...SONAR chooses to react to samples/buffer - I can't say I like that.  It's WAY too easy to max out CPU with just a few synths. (x86 or not)

2) That said, if SONAR keeps the whole "audio buffer/samples" measurement - then I need a way to change it - so I can "trick" SONAR into adhering to my actual CPU load (i.e. 5-15% approx).  Is there any setting - anywhere in SONAR - that lets me the user dictate how much "% CPU" I want to see before dropouts occur?  See, I thought there was - in the AUD INI file.  I tried to tell SONAR not to "Dropout" until X occured.  But no dice.  It only stops dropouts, not the increase in load itself - so after a few seconds, it still spiked up to 70% with crackles, etc.  But not one change that I made did anything - virtually identical results.

3) Finally, I think SONAR needs to change their CPU system, because it's over-reacting to each of my VSTi's individual CPU load - and then combining that with other tracks/VSTi, etc - until sure enough - I get 90%+ CPU. (When in reality, my actual CPU is about 9%).

I like that Reaper measures actual CPU.  I understand SONAR is different.  But, there has to be a way to compete with that - yes?  Is there any setting in the AUD INI file that actually makes a difference w/ CPU overreactions?  If I can't change what SONAR's CPU reads (buffers/samples instead of true CPU usage) - is there any way to tell SONAR to "ignore" the load, or not react with crackles/pops until 99%? or something...

I hope SONAR eventually changes their CPU - it's a real killer.

Please let me know if you can think of any manually fix - specifically for "fooling" SONAR into not reacting to the CPU loads in a buffer/sample way, and instead a true CPU load readout (i.e. Task Manager).

It's just too easy to max out my CPU in SONAR, and it's just not right. 

Thanks again guys!

I think you are looking at this the wrong way. What ever measure is used it needs to represent something that can be used to find out if it is going to let one know where the setup stands at any given time. Changing the CPU meter wont let you run any more tracks without a problem. That is all that matters. It indicates how much the system can deal with in a way that works.

In order to tell what any system can do i.e. Sonar versus Reaper for example one would need a benchmark project that both can run till one or the other fails.  Looking at the meter can help to tell when it will be at that point. Then one would need to be sure that all things in the projects are the same for both. I don't think that is possible.  

I wish SONAR's CPU actually measured just that: actual CPU usage.

\
Actually, what SONAR's CPU meter shows is the metric we're most interested in, which is how close to the ragged edge we are as far as being able to process data. Absolute CPU usage isn't nearly as helpful, since it doesn't correlate directly to audio processing headroom.

You may be at 30% total CPU usage when the audio engine runs out of steam, but somebody else with a better-optimized system might not hit that mark until they're at 70% absolute CPU usage. But no matter what the system specs, it's always useful to know that we're eating 60-70% of the available time for processing buffered audio data before the buffer overflows. That number is going to be significant regardless of the type and number of CPUs, or the number of background processes, or thread priorities, or deferred procedure calls or anything else.

I have no problem with adding an option to display absolute usage, but given the limited screen real estate on the status bar I'd still opt for the current method. And I can see the absolute usage now if I want to, just not in the SONAR status bar.

Is there any setting - anywhere in SONAR - that lets me the user dictate how much "% CPU" I want to see before dropouts occur? 

No, because there is no direct correlation between CPU usage and dropouts. If you're at 15% absolute CPU for the entire system, there is no way to extrapolate that to "I'm about to start getting dropouts". Absolute CPU usage means almost nothing to us while we're watching for potential dropouts.

Dropouts aren't necessarily even caused by CPU overload. A disk drive that's developing problems can cause dropouts, because it's having to recalibrate its position or having to perform redundant seeks, reads or writes. The great thing about SONAR's "CPU" display (it probably should be named something else to prevent confusion) is that it's a measurement of relative time, not CPU cycles. It tells you when you have a problem servicing buffers regardless of why the problem exists. You wouldn't necessarily know that by looking at an absolute CPU usage value.

I thought there was - in the AUD INI file.  I tried to tell SONAR not to "Dropout" until X occured.  But no dice.

Are you referring to the DropoutMsec setting? This merely determines the period of time a dropout can be ignored before the audio engine gives up. Its default value of 250ms is pretty long, long enough that if you get output buffer underruns for that long a period it's an indication that something is very, very wrong.

There can be no setting that overcomes the problem of data coming in too fast to be processed, or of insufficient data to feed output buffers. SONAR can't fill in blank spots. You're always going to get clicks and pops whenever the outgoing data stream is interrupted.


None of this is really relevant to your core problem, which is that you are running out of juice even when making only modest demands on your system.

Unfortunately, metering CPU usage isn't going to diagnose that problem for you. If you've exhausted your own expertise, maybe it's time to hire a technician to troubleshoot the problem for you. Or to buy a new, purpose-built computer.  You have my sincere sympathy, Benjamin. I feel your pain. But focusing on CPU metering isn't going to get you any closer to a resolution.

lorneyb2


The 1 thing I noticed is that your disk usage (at the bottom and in the large transport) was sitting at 0% in  both videos.  I assume you were still using a fairly high playback buffer setting so I would suspect that there should have been some disk buffering that should be taking place with that high a CPU load.   That could explain why it did not matter where you set your buffers it behaved the same.  It gives the appearance that the pagefile is not being accessed at all.  I am still running XP pro64 so am not familiar with pagefile/buffering configurations on Win 7 but that may be an area where configuration or conflict may be occurring.  Also ensure that all of you Windows .NET Framework updates are done as well including any of the optional ones available for your operating system. 

.NET is updated, yes.  But I'm curious about what you said before that - how would I go about adjusting my "Disk Usage" in a way you are talking about?  What tweak would I need to do to see results one way or the other?

Also, you are correct in your last post: I don't care what CPU says - just stop dropping out and clicking with just 4 synths.  Reaper can handle 18 VSTi's (CPU hungry) and plus a convo reverb on each insert - not even breaking a sweat.  Full polyphony.

I understand exactly what the previous poster(s) are saying about the importance of CPU vs. "real" CPU readings - I get it,  I've always understood that part.  It's just, why does SONAR overreact when other DAWs don't?  That needs to be addressed imo.  I also wrote about what SONAR's CPU really displays - I know that much.  It's just, if Cakewalk is going to display that CPU/cycles/buffer load - fine.  Awesome, I love that concept.  I don't need to see the Task Manager CPU meters at all.  But I'm just saying, Reaper IS a task manager style CPU - and as such, it lets me get away with murder - because it will never dropout/crackle at all.  I don't think I could even make my i7 CPU actually hit 100% in Task Manager, from just a DAW/synth lineup. (I'm sure I could but you know what I mean lol)

But, the SONAR CPU needs to respond as efficiently as say, Reaper, and NOT overreact incorrectly when it receives my synths...regardless of if they measure "different CPUs" or not.

Also, to the previous poster:
I have already tried that BIOS tweak - made no difference.  I put it back on, it's working fine - everything but SONAR.  So for now, I guess I just have to wait :(

I did as close as a "proper" test as I could.
I loaded 4 synths, same parameter settings, bit depth, background apps running, latency/buffer on ASIO, same polyphony, etc.

played same MIDI notes - then playback/record same file.

SONAR dropped out.  Reaper handled it flawlessly.  I then added 3 additional instances of each synth - and it still didn't hit 30% CPU in Reaper. That's with Gladiator at 256 voices by itself!

All I can tell you is that much, for sure. 

Thanks guys :)

No, it's not the reverb.  I only added that on at the very end of the trials - just to further prove how efficient Reaper was by comparison.  I had added reverb on top of all 4 synths in Reaper, and still didn't come close to SONAR using just one of the 4 synths.  That's all it was for.  I am aware that convo reverbs are quite CPU heavy indeed.

I did not test with reverbs until much later on in the testings.

The original problem had no FX processing of any kind, in either DAW.

And I agree 100% with what you said: The puzzle is why those synths incur more overhead in SONAR than in Reaper. That might be a question for CW Support, since they have every soft synth under the sun (and we don't).   :)

I just tried Gladiator in SONAR 8.5 - 256 voice polyphony.  No FX.  High buffers.  I played, w/ sustain pedal down, a C major scale from C1 to C6 and back down then random C major arps manually.

SONAR crashed 25 seconds into it at 88% CPU.  Dropout.
It's not certain synths that you could argue are coded poorly: it's any CPU hungry synth I have, made say, in the past 2 years or so - it just can't handle it.  It "sees" my CPU load per synth (buffers/samples) and cripples after very little pushing. 

Same synth setup: Reaper = 8% CPU, no issues at all.  I kept playing until my hands cramped :)

And yes, I know the CPU meters are different - I'm just saying - clearly SONAR is not handling the load properly - meters or not. 

hi benjamin are you sure your cpu is running in its full power? did you install the cpu utilities that came from your motherboard? check your cpu speed from there. we have the same problem, until i find out that my cpu is running ramdomly from 800 - 2800 mhz,  and it took me about one week to solve the problem. my cpu is amd 6 cores 2800 mhz, the latest cpu now like yours has its own  power saving settings inside the bios like cpu turbo mode, cpu cooling etc, that can never be change inside the window or sonar.

sorry for my english.

Lorney:

I'll see if I can get my Disk to increase and CPU decrease - that would be fine with me...if it balances out :) Come to think of it, lol I can't recall the last time I saw any activity on that Disk meter ;0

Also, the preset is standard with Massive, isn't it?  If not, sorry - I thought it was.

Cae:

Yes, my CPU/BIOS settings are set correctly.  Thanks! :)  You rock!

---

PerfectPrint:

I mentioned earlier in the thread that not all of my applications are stable enough for my comfort level, with respect to x64.  So, I'll move soon - promise ;)

Also, yes - I disabled on board audio from all other sources, minus the AP192.

I have read on other forums and posts here at Cakewalk (as well as talking to my buddies here in Beantown) - x64 users indeed have had similar unexplained "high" CPU dropouts - in modest/small VSTi projects...

A few of my non-audio applications mainly, but I'll go to x64 eventually.  I just got Win7 32 about 6 months ago - and this is the only problem I've had with any software so far.

I know the benefits of x64, but I have to wait a bit longer.  I'm certain my PC though, x86, can handle what I'm trying to do....

I just wish SONAR would respond differently....I hate leaving my main DAW for reasons/problem like this...It feels wrong lol - Like I'm cheating ;p

Benjamin -

This thread is relevant to my interests... my problems have been more related to latency than dropouts, but I also find that Reaper was giving me good results when compared with SONAR, and I was doing a *lot* of configuration parameter comparison trying to find the setting that was incorrect in SONAR - if it existed. My system specs are similar to yours, with a couple of important differences:
(Win7 64/8GB vs Win7 32/4GB). 

However I'm also running SONAR Producer 8.5 32-bit version.

Comparisons are tricky because our soundcards & drivers will be different, but if we can figure out a way it would help diagnose your problem, I would take a project that kills your SONAR config and run in on my system and observe the results.


I don't have the softsynths you mentioned. Can you reproduce the problem with stock patches in Dimension Pro, and email me (or upload somewhere) the project?


It's possible that the differences in system config will render the test non-useful - but if you want to give it a try, I'm game.

Sorry about using the word "crash".  Indeed, I mean dropouts/crackles and such.  SONAR has not truly crashed, in a sense of the program needing to be restarting, etc.

Apologies.

My CPUID/Hardware Monitor reports ice cold & healthy temps ;) No heat issues with respect to drives, CPU, GPU, etc.

Did you read about my Disk usage concern, above?  I was hoping Lorney would be able to reply this weekend - but if you know the answer, please feel free to share...

I can't seem to relieve any CPU by getting my "Disk" meter to register anything over 0%.  I've never seen any readouts on my Disk meter in SONAR - ever.

What did he mean by buffers, etc.?  I tried to respond with screenshots, but I don't follow...

Thanks!

I do not have any cached settings at all checked....

See above screenshot.

I'd love to balance my CPU and have it drop, at the expense of disk meter/usage :) Please...

I have 7200RPM drives,


Thanks!

Same here...I've used audio and VSTi/synths....no activity on the Disk meter....ever....

Hmmm

lorneyb2


Sorry to take so long getting back to you here.  Sometimes real work gets in the way  of coming here.
In reply to the Q about "Buffers  in Queue" that is not what I was referring to.  That setting is only for WDM mode I believe.  It was the Playback I/O Buffer size I was referring to or the Asio panel buffer setting for your Audiophile.  Perhaps with a Quad it may not need to do disk buffering.  With my system(much less powerful) there is a direct trade off of disk usage/CPU usage created by adjustments to the Playback I/O Buffer size"

In answer to Perfectprint's Q those read write caching boxes are a throwback to older system (Windows 95 or earlier I believe) and are not relevant in current Windows configurations.

I did find the following in the M-audio site for using the AP 192 in Sonar.  Maybe worth giving a shot to checking the box in "Other Settings" -  "Disable Direct Monitoring"  (see link below for whole article)  It is possible that that could cause the type of internal loop back I was referring to in reply #71.

             "If your device features hardware direct monitoring and you enable Input Echo in Sonar, you will need to disable the hardware direct monitoring of your M-Audio device to avoid doubling your monitored signal.  Please refer to the user guide for your M-Audio device for how to enable/disable hardware direct monitoring"

http://www.m-audio.com/in...075b2b9df638671975a8b4

I also came across some info regarding disabling the C1e support in the BIOS that may be relevant but I would definitely suggest more research on that before proceeding with that.  I know very little about playing around with BIOS settings. 

It would be interesting to know if the disk usage monitoring is now not applicable to Windows 7/Quad core systems or if there is enough CPU power that it is just not showing up until the system is being overtaxed

Thanks for the reply!  Yea, I saw that M audio article and changed that setting in my ASIO control panel - sadly, alas - no change in behavior.  I'm curious about disk behavior too....I'd love to balance the trade off w/ disk activity - if it would get me some more % CPU to play with ;)

been doing some more testing on my 6 core amd box running win7 4bit. 4gb ram.
Last night had EZdrummer with a couple of plugs in the chain plus live guitar recording and live bass recording both using a couple of very cpu easy plugs.
Saw 60% cpu usage at the star of the file which seemed to level out to around 35-40% as the track progressed. No apparent reduction inaudio density or level.
Odd.

Oh I am running 32 bit Sonar.

And beginning to llojk seriously at my other 2 core amd MACHINE RUNNING MUCH BIGGER PROJECTS IN REAPER 2.5.8 with minimal load and no dropouts.

And now the truly weird part.

I use an RME 9652 wih a couple of adat driven interaces hooked up.
I can set latency in the RME utility to anywhere from 32 buffer sie (almost no latency at all) to 512 and see NO difference in CPU usage.

And (much to my relief) so far the little project I have done is quite happy running at minimum buffer with no audio problems.

I for one am getting very confused by the whole thing.

In theory, six cores and 4gb should smoke anything I throw at it.
And before anyone asks my data drive is a SATA3 high speed one too.

...and there you have it.