Problem with the SONAR CPU meter please...?

I am making a video for you, with a soundtrack file...

:( Please take a look at it if you can...

I am only using 4 soft synths - and the SONAR buffer settings are set highest possible (i.e. not 5ms)

What settings would you fix in the Audio/Advanced, etc to fix this problem?  To alleviate playback strain ONLY (not recording) - so far recording gets into the red of CPU, 75%!! but the glitches seem to stop for now (since I change the 1 to 2 in AUD ini)....but still, they do happen...but now only 3-4 times out of 10 tests....vs. 10 out of 10....

This does not happen outside of SONAR.

I have this same project, but 2 instances of each synth - in Reaper - no glitching.  No dropouts.  Reaper's CPU footprint is just downright amazing.  I can't seem to bog it down no matter how many convolution revebs and soft synths I throw at it.....even in an x86 OS.  That to me, speaks for itself.  Now, I'd be happy to concede if I could find some setting or something in SONAR to combat this...but, I just can't :(  I don't know what else I can do, it anything is left to do...

I appreciate the help folks!! I owe ya bigtime ;)

Video link: http://www.mediafire.com/?2clmjca0vn64nl1
(2MB, MOV file)
..and the reason there is no audio is because it doesn't record the glitchy/crackles/playback glitches - it "renders" fine...but when you record/play the project back in SONAR it dropouts/crackles, of course.

You won't hear it on the mixdown...but I assure you, it sounds terrible - just terrible. Pure noise/crackles like 1000 firecrackers right in front of you.

Also:
Please don't overlook my last post (bottom of last page) - in case I refreshed it after you're reading this post :)
Thanks!

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!

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. 

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.  

check your bios settings, disabled cpu turbo mode, i hope it help.  

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.

John


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.  

That is just a symptom for him John. If you watch the Vid he did he is getting dropouts so it is not a Meter problem but a buffering problem or problem of some other nature.  He has indicated that he doesn't really care what the meters say, he wants it to work properly(ie without dropouts and an adequate number of synth instances loaded). 

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 :)

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.

Forget about metering, it is not in the slightest bit relevant to your problem.

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

First, make sure you're doing a true apples-to-apples comparison. There may be some other factor you're overlooking that accounts for the differences. I can tell you with certainty that 18 VSTi's are no problem on my (very modest) system, because I just did it last week. If there is an inherent limitation to the number of soft synths SONAR can manage it's a very large number.

Here's a thought: might the convolution reverbs you're mentioning be that elusive difference? Unless you're using the same third-party reverb in both DAWs, that would certainly qualify as a possible major variant.

And if it's Perfect Space that you're inserting on every track, well then mystery solved! That's a very CPU-intensive plugin that would normally not be used as a track insert.

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. 

I did a check via Taskmaster to see if the buffering appearing on the disk meter in Sonar was showing up in the pagefile usage, but alas, it does not.   While watching the pagefile  section when I load Sonar it goes up and when I add a synth it increases again.  It does not fluctuate with what I am doing with in the synth.  I do however find it strange that you are not getting any disk activity showing on your meter.  When I increase my playback buffer within Sonar I see an increase in the disk meter and decrease on the CPU usage meter.  Vice versa for decreasing buffers.   I loaded an instance of massive with 64 voicings  in a project that has 50 tracks and it didn't make any significant difference to the load when I was banging around on the keys.   Again I am doing 64bit but in terms of the load it should not make a significant difference. 

Can you export the preset and see if someone who is running WIN 7 32BIT and has Massive can test it to make sure it is not related to the Preset itself within Sonar (creating some internal loop back). 

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.

Sorry to hear about all the trouble you are having. I had a rocky start with my build and it took about a week of tweaking and playing around to get a stable system. Hope fully if you keep at it you can figure out the problem.

Have you disabled your onboard audio (if your mobo has it) and made the necessary changes in windows audio setting?

I see you stated earlier " There is absolutely zero guarantee that x64 would fix this problem 100% - it's possible, but as I've said before - people from both OS camps have similar CPU problems, x86 and 64. " can you provide citations for x64 users having the same problems?

I know you said you weren't willing to switch to x64, but I think you should. 32 bit applications have no trouble running in 64, I am pretty sure your audio drivers are available for x64, so what is your concern about making the switch?

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

which applications are you worried about in x64?

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

lorneyb2


I did a check via Taskmaster to see if the buffering appearing on the disk meter in Sonar was showing up in the pagefile usage, but alas, it does not.   While watching the pagefile  section when I load Sonar it goes up and when I add a synth it increases again.  It does not fluctuate with what I am doing with in the synth.  I do however find it strange that you are not getting any disk activity showing on your meter.  When I increase my playback buffer within Sonar I see an increase in the disk meter and decrease on the CPU usage meter.  Vice versa for decreasing buffers.   I loaded an instance of massive with 64 voicings  in a project that has 50 tracks and it didn't make any significant difference to the load when I was banging around on the keys.   Again I am doing 64bit but in terms of the load it should not make a significant difference. 

Can you export the preset and see if someone who is running WIN 7 32BIT and has Massive can test it to make sure it is not related to the Preset itself within Sonar (creating some internal loop back). 

I was wondering -

is that what you mean?  The "Buffers in Playback" setting is grayed out - it always is when I use any ASIO driver, I think...I could be wrong, but I recall never having to adjust that setting (or be able to).

Or is there another setting you were talking about?  I'd love to see some Disk Usage - but as I said above in an earlier post, I've never seen any activity in that Disk meter - ever.  ;) Cure?




I even tried that setting, in playback - to max it out, and sure enough - it did make a "little" difference in CPU, but of course for playback only.  It lowered the CPU on playback by about 12%.  However, disk usage never budged from 0%.  I can't seem to use my disk lol ;)

Can you walk me through what you did, and how I can get Disk usage? Thanks!

I can't for the life of me find any way to increase my Disk/Meter in SONAR from 0% to anything....now that you mentioned it.  How can I fix that?  Surely, that has to be a factor :)  See...now I'm optimistic, hehe....


*PS.  Yes, I've tried switching off those two checkboxes with Multi and Share Drivers....no difference, fwiw.

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.

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.

So when you say crash, you mean crash? Not dropout? A crash where Sonar goes away? I'm confused because you say crash, then dropout. Let's be clear that a dropout or crackle is not a crash.

What are your system temperatures?

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!

No readout on your disk meter means you have read/record caching checked in your Options>Audio>Advanced settings.

Can someone explain the usefulness of disc caching?

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!

never seen any disk activity in that sonar meter either. thought it was because I usually just use vst instruments and no live audio tracks.

but.. I started work on a remix, with a bunch of vocal tracks.. still no disk activity in that indicator when I play back audio tracks.

I have no idea what disk it's supposed to be tracking.

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

Hmmm

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.

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 ;)

This thread is also relevant to me. I am getting unexplained dropouts with low cpu readings on a very similar hardware system as the OP.  In my case, sound quality is awesome, then the engine just stops randomly. I've disabled all startup programs, re-installed my interface drivers,  thoroughly experimented with my buffer settings, and the latency checker shows no spikes. Not every project issues and I've come to the semi-conclusion that it seems to be linked to softsynth usage, due to the projects characteristics where I'm seeing the most dropouts. 
 
One thing to note is that I've systematically removed all soft synths and effects from one problem project in particular without luck.  I haven't mucked with aud.ini yet and I'm still in the diagnostic stage on a relatively new build, but I feel your pain...
 
Vernon

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.

Well, good news and bad news.

Bad news is, indeed, more quasi-proof that SONAR is to blame.  Inefficient core load, CPU, whatever you want to call it.

I just ReWired Reaper 3.66 into SONAR, as a ReWire insrument - flawless.  Reaper-quality low CPU --> SONAR 8.5 PE.  I am now enjoying INSANELY low CPU for 30+ synths!! I'm so happy I can still use SONAR as my main host.

Sadly though, if I open just a few of those very same synths 'direct' in SONAR, 65% CPU spikes, etc - using "just" 32 voices, vs 256 I'm using now (PER synth).

I'm not sure what this proves, per say, but ReWire Reaper into SONAR and you'll get MAJOR relief on your CPU/dropouts.

I can submix my tracks into SONAR, MIDI channels work great - it's awesome.  All the CPU perks of Reaper, into my favorite DAW - SONAR.  :) Happy me.

Hope this helps others.  I hope SONAR improves on CPU engine tweaks. :( I'm not sure what needs to be done, but it's clear that SONAR is "partially" the problem here.


I tried one instance of Gladiator, 256 voice polyphony in Reaper -> ReWire -> SONAR 8.5 - all voices used = 3% CPU in SONAR meter.
I tried one instance of Gladiator, 256 voice polyphony in SONAR 8.5 directly - all voices used = 68% CPU in SONAR meter.
This time it is constant, same DAW meter - same readout - only difference, is the synth is "loaded" in Reaper and NOT directly in SONAR.
Apples to Apples, this time.

CPU meter is the constant now.  Drastic CPU differences.

It is a SONAR issue. 

...and there you have it.

Double Post

acoustic12


...and there you have it.

Meaning?

d`Oh he is referring to your previous post.

Unfortunately I (and I suspect you) don`t feel like the rewire workaround is very satisfactory - I am still very uncomfprtable with a cpu load that hovers around break point with very little hooked up in Sonar.

Another reason to finally get off the fence between Reaper and Sonar, I guess.
Trouble is I have been with Sonar a long time and hate to move permanently to something different and then see the issues I currently have either resolved or explained.
I always get he feeling that any problems I have are very likely down to me just not knowing what I am doing properly.

But I would like to see an explanation from Cake of "our" problem here.

Just out of interest, based on an article I saw in one of the other forums  when I was looking for info for your audiophile, I came across  someone who stated that the earlier versions of Sonar 8.5 work(ed) fine  but  8.5.3 created problems for his  M-Audio(delta series) which I believe you are using.  If you have your original 8.5.0 upgrade/original disc  it may be worthwhile trying each of the previous versions and see if there is any better behaviour with 1 of the previous editions.  If there is a change in function between versions then you could submit a ticket to support that would narrow down the cause of the problem more readily. 

Regardless of the above I think you should submit a support ticket to support, if you haven't already done so. 

ivanSC


d`Oh he is referring to your previous post.

Unfortunately I (and I suspect you) don`t feel like the rewire workaround is very satisfactory - I am still very uncomfprtable with a cpu load that hovers around break point with very little hooked up in Sonar.

Another reason to finally get off the fence between Reaper and Sonar, I guess.
Trouble is I have been with Sonar a long time and hate to move permanently to something different and then see the issues I currently have either resolved or explained.
I always get he feeling that any problems I have are very likely down to me just not knowing what I am doing properly.

But I would like to see an explanation from Cake of "our" problem here.

Yea, for now I'll ReWire but hopefully Cake will address it - if they can.  I love SONAR and it's my favorite DAW, for years now.  No intention of leaving it.  But damn, this is frustrating.

And yes, to the other poster - I have tried downgrading temporarily - no such luck.

It's actually a bit worse than 8.5.3

But I would like to see an explanation from Cake of "our" problem here.

You're not going to get an explanation here on a peer-to-peer forum, only speculation from other users who don't have the same soft synths, can't reproduce your problem, and don't experience this problem with the synths they use. Open a support request!

CW tries to work with third-party vendors to assure compatibility. And that's what this is, a compatibility issue. It's not SONAR that's chewing up those CPU cycles, it's the synth. It may be because of some miscommunication that's SONAR's fault, or that SONAR could somehow avoid, but it's still specific to your synth. The only way you're going to solve the mystery is by getting CW support involved.

bitflipper

But I would like to see an explanation from Cake of "our" problem here.

You're not going to get an explanation here on a peer-to-peer forum, only speculation from other users who don't have the same soft synths, can't reproduce your problem, and don't experience this problem with the synths they use. Open a support request!

CW tries to work with third-party vendors to assure compatibility. And that's what this is, a compatibility issue. It's not SONAR that's chewing up those CPU cycles, it's the synth. It may be because of some miscommunication that's SONAR's fault, or that SONAR could somehow avoid, but it's still specific to your synth. The only way you're going to solve the mystery is by getting CW support involved.

I thought the same at first, about compatibility - but if that's the case then you are saying 30+ synths that are "faulty" - but not SONAR?  It's more than just a simple miscommunication, imo.  Yet these same synths work flawlessly in Reaper?  I'm not meaning to pick on SONAR, I just want to understand the problem and fix it.  How can the synths be to blame?  The only common factor is SONAR.  I've been happy with SONAR for years, but recently since I've upgraded to 8.0 and now 8.5, this is getting way worse.

Look at the last test I posted (above/recent post).  ReWiring the same synths in SONAR cause SONAR's CPU meter to run perfectly.  Run those synths "in" SONAR directly, and SONAR locks up and dropouts/clicks/pops.  I'm confused with what you mean...

If it were the synths, then shouldn't they max out Reaper's CPU and RAM or whatever too?  But they don't.  When I 'load' the synths in Reaper, and ReWire into SONAR, SONAR does not spike or dropout at all.  I can load 50 instances of Absynth, Rhino, Rapture, even Largo.  So, I really can't agree it's primarily the synths fault.  That's saying virtually all my synths are "faulty", per say, but SONAR is not?  Or am I misunderstanding?  I agree with you: it 'may be' (i.e. it is) SONAR's fault, with respect to a massive miscommuincation.  But it is specific to SONAR.  The ReWire proves it.  No?

I mean, why else would Reaper 'hosting' the synth "cure" SONAR's CPU spike completely - 100% - and yet, if I load those synths in SONAR directly, it dropouts and clicks/pops/freezes. 

The way I see it: It's a SONAR problem, and it just happens to involve VST/VSTi technology.  That's my opinion, based on the days of testing I've had to do.  I've spent every waking second I could on this, so I really think I'm onto something.  SONAR is causing the CPU cycles to blow out of control.  There has to be something in "how" SONAR sees these "types" of synths (i.e. powerful CPU demanding ones).  Maybe it's quad CPU related, i7, .dll/coding, etc - I don't know.  But SONAR is the main culprit, imo.  Every test I've done shows that, at least to me.  ReWire surprised me; but the proof is in the pudding.  I can load 50 synths in Reaper -> ReWire -> SONAR, and SONAR CPU meter = minuscule.  Load 10 of those same synths in SONAR straight up, and massive dropouts/clicks and pops - and it just gets worse as you add more to the project.
I'm now using apples to apples - comparing SONAR CPU meter to SONAR CPU meter.  That's the key, now.

 I'm going to contact CW, because there is definitely something under the hood causing this.  I've tried everything here and the Reaper ReWire really made things click for me.  Think about it :)

Personally, I think it's SONAR that has the "problem" understanding "certain" synths, yes.  Any synth, created in the past few years that is "CPU hungry", seems to be the problem in SONAR 8.5.3

But there are so many synths out there now, and other DAWs just simply don't have this problem using the same setup.  So, I'm trying to figure it out as best I can.  I wish I knew more about the way programs are coded and such.

We'll see how it turns out.   I'll post what I hear back from CW.  :) Thanks for all the help guys, this place rocks!

Ben

On earlier post when mentioning buffers I didn't mention the one under OPTIONS - GLOBAL - MIDI  Prepare using you could maybe try an adjustment there.  On my 64bit I use 500ms but on my 32bit I use 1000.(it can be anywhere from 20 - 10,000)  Also the Sysex buffers(likely irrevelent) I have set at 128. I think default is  64.

Also under OPTIONS - GLOBAL - GENERAL try turning off the Enable Xray(at the bottom) if it is on.  I recall from other posts that it created problems for some but don't remember of what nature but may be worth a shot. 

lorneyb2


On earlier post when mentioning buffers I didn't mention the one under OPTIONS - GLOBAL - MIDI  Prepare using you could maybe try an adjustment there.  On my 64bit I use 500ms but on my 32bit I use 1000.(it can be anywhere from 20 - 10,000)  Also the Sysex buffers(likely irrevelent) I have set at 128. I think default is  64.

Also under OPTIONS - GLOBAL - GENERAL try turning off the Enable Xray(at the bottom) if it is on.  I recall from other posts that it created problems for some but don't remember of what nature but may be worth a shot. 

Hi Lorney:

Oh, good idea.  I just tried to adjust some MIDI settings in that area, but I'm not seeing any results - yet. 

Thanks! :)  I'll let you guys know what I hear back from Cake.

Ben

I'll let you guys know what I hear back from Cake.

Yeah, I was going to suggest you contact them with all that you uncovered regarding rewiring the synth through Reaper, vs having the synth in Sonar. Hope something comes of it.

I agree there is an issue with Sonar and it's resource usage with VSTi's.
There have been so many people complain on this forum about similar issues, most give up and are never heard from again. I'm just a hobbyist so I never need to load more than a couple of synths, but that will still push the Sonar CPU meter up to 50%, add an instance of Guitar Rig and the crackle and pops start.
Like you I can run the same setup in Reaper and never have an issue, also like you I prefer Sonar though and don't want to switch.
Not sure what the issue is, could it be a combination of Sonar and Windows 7/Vista, Iv'e noticed that many of the folks that never have a problem are still on XP ???

Exactly.  Like I've been saying, I love SONAR - but that doesn't mean I can't point out flaws right?

I'm only using Reaper to ReWire in my large projects that normally would bring SONAR to its knees.

The issue became quite clear when I could ReWire loads of heavy CPU synths into SONAR, and SONAR's CPU meter itself barely flinched :) I was so happy to see 4% with all that I had going on. But direct loading in SONAR?  Forget it.  Sadly, just a few synths at say, 16 voices per synth, cause SONAR to dropout and glitch up :(  I could use Rapture at like 500 voices x3 instances lol just for the heck of it ;p via ReWire.

It's definitely not the synth makers - they are pushing the envelope with their CPU-resource hungry VSTi's - without problems - but it's SONAR that can't keep up.  Other DAWs can just fine. 


I'll report my findings from Cake.

Ben

you are saying 30+ synths that are "faulty"

Sorry, I was under the impression that it was a handful of specific synths that were having the problem ("certain soft synths" was the phrase in your initial post).

But if you've reproduced the behavior on 30 different products, then that's a whole 'nother dimension. It would suggest something systemic in nature, but also something out of the ordinary. Unfortunately, I don't have any of the synths you've mentioned, so I can't try to duplicate the problem. I'd hope that somebody will eventually comment who does have them.

Have you experimented with synths that others here are likely to also have access to, such as Dimension Pro?

My little trial the other night I had only one piece of non-cake software running and that was ezdrummer. all other plugs used were cake ones.
I really hope the OP gets a good answer from Cake support.

bitflipper

you are saying 30+ synths that are "faulty"

Sorry, I was under the impression that it was a handful of specific synths that were having the problem ("certain soft synths" was the phrase in your initial post).

But if you've reproduced the behavior on 30 different products, then that's a whole 'nother dimension. It would suggest something systemic in nature, but also something out of the ordinary. Unfortunately, I don't have any of the synths you've mentioned, so I can't try to duplicate the problem. I'd hope that somebody will eventually comment who does have them.

Have you experimented with synths that others here are likely to also have access to, such as Dimension Pro?

Yea, but Rapture and DimPro (at reasonably modest polyphony and FX) don't take up as much CPU as newer 'CPU intensive' synths do - though, to be fair, after I pushed them hard they too caused issues with CPU in SONAR.  But it took more before they dropped out.

Ben

I can't reproduce your findings.
Do you have a problematic setup using DimPro that I could load and check out?
 
Also, have you checked that your hardware and OS combo are fully supported by Microsoft? 

BC - Any word back from Cake on "our" problem yet?

Based on everything I have read and all your testing I believe Sonar has a problem with one of there updates between Sonar 7 and 8.

That is where I would put my money.

^^^And you may have put that money right on the spot

I just upgraded to 8.5 from Sonar 6 earlier this week. I had session 3 along with dimension going at the same time and it hit the red on some occasions. Opened up these same two synths in 6 and it was around 18%.

Yeah, my PC may be a few years old, but it still reaches the reccomended requirements for Sonar 8.

Are you using ASIO or WDM???

Is Sonar 8.0 working for you? I have the same problem with 8.5.3. I just reverted back to 8.0.

This is a very interesting thread, as something similar has led me to upgrade my computer twice after getting Sonar 8.5 (the first time to an Intel i3, which still left me with lots of dropouts and very high CPU meter readings).  My new rig is an i7 quad-core with 4GB RAM, Win7/64, which MUST be enough to handle SONAR 8.5.3 PE with two plug-ins (Session Drummer and Guitar Rig LE) ... right?  Well, imagine my surprise when I opened a file (again, with just these two plugins) and the meter went to 50+% at idle and kept dropping out during playback!
 
Thanks to this thread, I've tweaked this every way to Sunday.  Some made no difference at all (changing the I/O Buffers in either direction), and some made a meaningful difference (turning off/disabling every background/non-audio process ... including, in particular, wifi).
 
Now I don't seem to get dropouts, but the CPU meter is still up in the 50% range ... and I'm not pushing it at all.  One thing that I found very interesting was changing the CPU Meter Mode in the Cakewalk.ini file from the default (the big green bar is the peak single-core usage and the yellow stripe is the average of all cores) to showing a separate bar for all 8 processor cores.  Turns out that Core 1 is running at 50+% and the other 7 are much lower -- in the 0-2% range -- so that the average CPU load is down under 10%. 
 
That's a relief, but shouldln't this be load-balancing better between the cores?  I'm pretty sure that if I start to add more load, core 1 is going to spike into the red territory and I'm going to start getting dropouts again.
 
I'm using a Firebox with ASIO 64-bit drivers.  I haven't tried the WDM drivers (in the past, I had bad latency issues with them), and I haven't yet tried it with the mobo audio (some combination of NVIDEA and Realtek, I think) to see if the Firebox driver has something to do with this.   
 
But my question for this forum is, should I be setting something in Sonar to load-balance across my 4 actual/8 virtual processor cores?  Seems like all the work is being done by core one ... and it's quickly getting overloaded.
 
Thank you.

Very good question re load balancing. I have been busy up in London the last few days & still have no time to play with settings.
Anyone gets any definitive answer to how we go about using all the cores we got in an efficient way, I for one would be very grateful for some pointers.

I am SOOOOO disappointed with Sonar/Cake for the moment, but hopefully this is either a blip or us not RTFM`ing enough...
and in the meantime there is always Reaper

There is a switch in AUD.INI that supposedly opens up a new processor core thread (set ThreadSchedulingModel=<0 - 2>  to 2), which one would assume would balance the load to some degree, but I tried it and it made no difference whatsoever.  All the work is still being done by core 1 ...

I hope there's a setting somewhere that I don't know about ...

BUMP.

I am still seeing high activity in Sonars cpu meter that is not matched by the system cpu usage meter.
Also experiencing dropouts and pops and crackles sporadically.

Any news from Cake tech support yet?

I may have to contact them myself jsut to ad a little extra squeakiness to the wheel

I just noticed a thread on this board that talks about how to tweak the Win7 registry to disable core parking.  It seems to have helped the load balancing situation for some other users.  I haven't tried it yet (not thrilled about messing about in the registry, to be honest) ... but here's the thread if anyone else is interested:
http://forum.cakewalk.com/tm.aspx?&m=1722043&mpage=2

Otherwise, no progress on my end.  If this tweak doesn't work, I'll probably call CW support this week, too ...

Would be nice to know more about this before I install my PE 8.5 that's been on the shelf about two months now...

Well, I did the registry tweak, and I can't say there's a huge improvement in load balancing across cores (CPU 1 still does almost all the work).  But it doesn't appear to have broken anything!

More important, I followed some msconfig instructions I found on the Presonus website, here: http://support.presonus.com/entries/119099-optimizing-your-computer-for-audio-windows-vista-windows-7.  My new computer is a Sony laptop, and it was CRAMMED with services and startup programs I didn't need or even recognize.  I disabled almost everything (except audio drivers and Windows processes -- though I did turn off Search and Superfetch).  Now my cpu load is more reasonable (25% on one of eight cores) ... and for the first time ever, I'm not getting frequent pops, dropouts and audio engine crashes.  

Sonar is still not load balancing very well, but at least I can now use it!

Would be nice to know more about this before I install my PE 8.5 that's been on the shelf about two months now

Just install it. It will probably work just fine for you. If not, you can still use your current version without any change.

ddundas. Did you use the LAST registry tweak in that thread?
Follow it and see what my result was.

Worked great for me.