Problem with the SONAR CPU meter please...?

Benjamincharles; I have to thank you for how well you answered my questions and the grace you showed in doing so.  I also have to agree with Brundlefly that this is a job for tech support. This problem seems without a doubt above our pay grade.

I do hope you get this sorted out and as well the others. I will say this you have brought to light something we were as a group unaware of. For that you have done us all a great service.

brundlefly

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

True. I'm not familiar with a couple of the softsynths he is (or the others with similar problems are) using, so I don't know if any would access the drive.

Good catch though, Brundlefly!

Thank you all, for trying your best!

Planetearth:

Yes, I've done a clean install of my OS, and installed only SONAR (nothing else, just standard Win7 x86).

I hear what you're saying about what SONAR 9 could really "fix" at this point? - I guess, for lack of better words, maybe this:

"better CPU efficiency with regards to VSTi" or "better handling of i7/multithreading/CPU/loads"?

------
I know what you mean, it's tough to have them "fix" such a general, and quite honestly "odd" problem.  But I have faith in Cake!  The fact that other DAWs or "hosts" can handle this CPU load flawlessly proves that it's possible.  I can feel it! :)

SONAR is the best DAW, seriously.  Mad powerful!  I just wish I could load my synths in it :(

But, I'm a very patient and understanding person.  I know I'm just one user.  But this community rocks!

Thanks again everyone.

John


Benjamincharles; I have to thank you for how well you answered my questions and the grace you showed in doing so.  I also have to agree with Brundlefly that this is a job for tech support. This problem seems without a doubt above our pay grade.

I do hope you get this sorted out and as well the others. I will say this you have brought to light something we were as a group unaware of. For that you have done us all a great service.

My pleasure! I wanted to help others through sharing my problems.  And also, hopefully - solve my problem as well :)

I'm glad I could help bring light to this.  I honestly feel like it's a simple fix (as far as coding/engine work under the hood in SONAR) in order to just allow SONAR to be more efficient with CPU-heavy synths and FX (VST).  I am confident that SONAR will address this over time!
(Soon I hope, hehe)

Thanks again!

Thanks, Benjamin.

Have you had any luck with Cakewalk support?

Well I am planning a weekend of serious testing and reinstalling. I am determined to get to the bottom of this.
Last night I banged out a project with 3 audio tracks - a guitar, a double bass and an electric guitar - all recorded using zero plugs.
I had one instance of EZdrummer with the default pop rock kit loaded playing a very basic MIDI track that I had moused in.
By the time I had ezdrummer and the first guitar track up, the bass part was already pushing cpu usage in Sonar up over 40% but no glitches or red lights.
 When I recorded the second guitar part, I was getting intermittent glitches, pops and crackles.
This was with the latency on my rme set to 128 samples.
Task Manager showed my ram usage overall at around 1.5gb and minimal core activity - maxed at around 11%

Bear in mind this is with Win7 64 and Sonar 8.5.3 64 & with a 6 core AMD cpu,  fast SATA 3 data drive and 4gb of 1333 DDR3 ram.
I HAVE to be doing something wrong here, surely?

And predictably when I attempt the same thing in Reaper all is well.

I don`t have enough  hair left to lose tearing it out over this...

And yes, thanks for your patience and all your efforts, chaps.

I WILL resolve this.

Bear in mind this is with Win7 64 and Sonar 8.5.3 64 & with a 6 core AMD cpu, fast SATA 3 data drive and 4gb of 1333 DDR3 ram. I HAVE to be doing something wrong here, surely?

I agree - something is bogus in your setup.  I'm working on a 24 track with over 50 plugs and Sonar CPU is ~22%.
 
What interface are you using?

What are your midi buffers set to?

What is your ExtraPluginBufs in the aud.ini file set to?

What is your ThreadSchedulingModel in the aud.ini file set to?

Also, if you're using 32 bit, why are you on Win7 instead of XP?

Even XP wasn't stable enough to reliably run a studio machine until sp2, and didn't fully mature until sp3. Win7 is still half-baked, and if you look at the problem threads on this forum, a majority of the people complaining are using Win7. I've got a modest single-core Athlon XP 2500 that I use to test plugs with Sonar and to surf the internet, and I can run 30 tracks of audio, 30 compressors, and 30 EQs without a dropout on a twelve year-old LynxOne card. I haven't even tried to max out my new quad-core, but I have yet to see any weird behavior. Both machines are running a fully updated XPsp3 Pro install. There's definitely something wrong with your setup, and I'm willing to bet there's some type of conflict between your hardware, Win7, and Sonar. While Reaper may be able to run more efficiently, my own studies show that Sonar runs the same plugs as Reaper in relatively the same fashion. Compared with the stats in the windows task, Sonar regularly overestimates the cpu usage while Reaper under reports it. One problem I've had with Reaper is the cpu load for routing tracks. (I also have problems with the phase issues and the lack of a sinusoidal curve for panning, but that's a different discussion.) I still use Reaper for recording my live jams with Reaktor and soft synths like the Moog Modular, but in the end, I've found Sonar best for actually putting it all together.

From the Cakewalk help file:

"CPU meter. The CPU meter displays the time it takes to process a buffer full of audio data as a percentage of the maximum time available to process that data and maintain uninterrupted playback. There is some tolerance built into the meter, so it's very possible that it will exceed 100% at times (more so during recording than playback). When the meter exceeds 100%, it displays the word "Overload"."

If you're not getting full use out of your cpu, then there is definitely a conflict.

Just to remind you, I am running 64bit and have thus far tried XP32 and 64, plus Win7 32 & 64.

I am not just casually moaning here.
I have been shuffling as many of the variables as I could.
Also have two multicore AMD based machines side by side & only the 6 core seems to be struggling.
The `old` AMD AM2 based dual core machine has an Emu 1212m pci card, but on the new AMD AM3 based 6 core I decided to get a more professional card & went with the rme hdsp9652 pci card.
That is the machine with all the problems.
I`m off to explore the `*.ini` settings mentioned in the post ahead of this one....

Resonant Order


What are your midi buffers set to?

What is your ExtraPluginBufs in the aud.ini file set to?

What is your ThreadSchedulingModel in the aud.ini file set to?

 
 
 
So THATs what the aud.ini references were about.
Where does one find this mythical file?

Second post by bitflipper in this thread:

http://forum.cakewalk.com/tm.aspx?m=2012466

Thanks - having read the whole lot two or three times over the last few days you`d think that would have stuk in my subconcious.
I plead being old and infirm...

I may have missed it, but I was looking for references to network connectivity and certain task manager details by benjamincharles.

Whatever Sonar is doing differently from the other DAWs, it is still worth looking for whatever your computer is doing differently from everyone else's. These could be goose chases, but ...

The reason I asked about networking is there are some network cards that require a periodic software loop to check for connectivity. For these cards, unplugging the network connection causes the system to perform worse than having it plugged in. Also, wireless networking can cause problems.

Another thing is I don't recall benjamincharles reporting how the CPU usage is distributed among the cores (in the "performance" tab of task manager) when Sonar is running. Also, in the "Processes" tab, right-click the sonar process and select "Set Affinity..." to make sure someone didn't deselect some of the CPUs.

Bill B.

What does RME say?

bvideo


I may have missed it, but I was looking for references to network connectivity and certain task manager details by benjamincharles.

Whatever Sonar is doing differently from the other DAWs, it is still worth looking for whatever your computer is doing differently from everyone else's. These could be goose chases, but ...

The reason I asked about networking is there are some network cards that require a periodic software loop to check for connectivity. For these cards, unplugging the network connection causes the system to perform worse than having it plugged in. Also, wireless networking can cause problems.

Another thing is I don't recall benjamincharles reporting how the CPU usage is distributed among the cores (in the "performance" tab of task manager) when Sonar is running. Also, in the "Processes" tab, right-click the sonar process and select "Set Affinity..." to make sure someone didn't deselect some of the CPUs.

Bill B.

All cores are even, no parked cores.  No odd behavior.  Good distribution among cores, fwiw.  All across the board, all apps, not just SONAR.  Not once has the Task/Resource manager ever showed any red flags.  Not one time, I have found.

SONAR on the other hand, itself....

Can you please update your footer/signature with the current hardware/software you are running?
 
For example, are you still loading the Alphatrack and its drivers?
(There are mentions of some issues from users running Sonar... I notice that the AlphaTrack installs some control drivers in Sonar... but not in Raper).

tried changing the ini file.. but can't seem to make the changes stick. always defaults back to 1.

 
This happens to me as well, on Win7 64.
 
"when you save the aud ini reload the config and it will come up 2"
Ok, now it stays on 2 for me.

tried changing the ini file.. but can't seem to make the changes stick. always defaults back to 1.

 This happens to me as well, on Win7 64.

Are you trying to change the actual file, or are you using the Options/Initialization File procedure in Sonar to change the file?

Sijel


Can you please update your footer/signature with the current hardware/software you are running?
 
For example, are you still loading the Alphatrack and its drivers?
(There are mentions of some issues from users running Sonar... I notice that the AlphaTrack installs some control drivers in Sonar... but not in Raper).

?

My signature is accurate.  I have since moved on with reinstalling other programs and will be contacting Cake support to see what they can offer.  I had to move on.  My work was suffering and I have to pay bills.  I think a few weeks of downtime (i.e. several minimal/limited workflow) is enough for now.  :)

Alphatrack works flawlessly in SONAR, fully functioning - couldn't live without it!  No lie.

The Alphatrack does work in Reaper, technically, but it's not nearly as fluid, flexible and powerful (at least "out of the box").  I know many who design their own MIDI setups, but I just haven't done it yet.

Well I did nothing last night - forgot we had a rehearsal scheduled!

FWIW I have contacted rme and got no response other than "well if it is working OK with one app it shoul be OK with all apps" which of course makes perfect sense.

I suppose one thing I havent tried is moving my Emu 1212m over to the 6 core to see if that affects anything. Lot of effort, though.
I will have a couple of hours to work on this tonight and then I am out of the loop till Sunday unfortunately.

Don't know if this is useful but the third link looks like something that could help?

http://www.rme-audio.de/forum/viewtopic.php?id=1704

Well I did nothing last night - forgot we had a rehearsal scheduled! FWIW I have contacted rme and got no response other than "well if it is working OK with one app it shoul be OK with all apps" which of course makes perfect sense. I suppose one thing I havent tried is moving my Emu 1212m over to the 6 core to see if that affects anything. Lot of effort, though. I will have a couple of hours to work on this tonight and then I am out of the loop till Sunday unfortunately.

Make sure all the AMD Cool n' Quiet operations are turned off. You might want to start a new thread listing all your specs, and we might be able to get down to the problem since there's usually a checklist to go by. I always use AMD because of the great performance.

Agreed. I have a few days of busy, but once I get the chance to make sure I have explored all avenues suggested on here again, I will start a new thread.
 
I really really DONT want to be  a PC engineer, I want to be a musician again! 

This may be of some relevance.

Today, I upgraded my CPU from a Phenom X3 (2.3 GHz) to a Phenom II X4 (3.4 GHz).  So you can guess that I was pretty astonished to open a test project that I have going in Sonar and find the CPU use reported by Sonar had almost doubled from ~15% to ~25%.

At any rate, I stumbled around a bit and ran into what appears to be the issue (at least as far as reporting goes):

With the normal power plans, the OS and CPU will run the multiplier up and down so that the CPU doesn't work as hard if there isn't as much to do.  Putting the power plan to max performance locks the multiplier and speed of the CPU at the top end.

I can't remember if you did that (and don't have the stamina to read all these posts again) , but that would be worth a try.  I found a nice desktop gadget (powerscheme) that will let me select power plans with a single click.

If that fixes the problem, then I suspect that the difference with Reaper is that Reaper has code that bumps up the power plan.  that would explain your rewire result, since with Rewire, the Rewired application is actually still running.

If all you do is music on the machine, you might just leave in on Max Performance or disable the features (I'm pretty sure it's cool and quiet on AMD, not sure on Intel).  But if you have a mixed use box, then just switch into Max Performance whenever you run Sonar.

I hope that's of some use.

Just ran an experiment in (Propellerheads) Record.  It idles with the multiplier @4, but when playing back, it locks in at 17 (the max) and doesn't change at all.

Over to Sonar, opens at 4, and plays the song back at 4. There's not much that's CPU heavy in my test project, but I expect that if there was, I would be getting drop outs.

I think this might explain why the newer, higher performance CPUs are more prone to this issue: they keep optimizing the power saving features of these chips.

AndyDavis


This may be of some relevance.

Today, I upgraded my CPU from a Phenom X3 (2.3 GHz) to a Phenom II X4 (3.4 GHz).  So you can guess that I was pretty astonished to open a test project that I have going in Sonar and find the CPU use reported by Sonar had almost doubled from ~15% to ~25%.

At any rate, I stumbled around a bit and ran into what appears to be the issue (at least as far as reporting goes):

With the normal power plans, the OS and CPU will run the multiplier up and down so that the CPU doesn't work as hard if there isn't as much to do.  Putting the power plan to max performance locks the multiplier and speed of the CPU at the top end.

I can't remember if you did that (and don't have the stamina to read all these posts again) , but that would be worth a try.  I found a nice desktop gadget (powerscheme) that will let me select power plans with a single click.

If that fixes the problem, then I suspect that the difference with Reaper is that Reaper has code that bumps up the power plan.  that would explain your rewire result, since with Rewire, the Rewired application is actually still running.

If all you do is music on the machine, you might just leave in on Max Performance or disable the features (I'm pretty sure it's cool and quiet on AMD, not sure on Intel).  But if you have a mixed use box, then just switch into Max Performance whenever you run Sonar.

I hope that's of some use.

 
Thanks for trying but I suspect this was the first thing all of us with the problem tried.
I am planning on starting a new thread once I have time to set some benchmarks on exactly what is going on, unless I get lucky and find a cure, in which case I will post my findings on here.
 
This all just so weird.

I'm experiencing the same problem.
Sonar is unstable with dual core cpu and Multiprocessing Engine option set to On.
When Multiprocessing Engine option is off, it becomes much more stable,   
but seems to be using only one core...


Sagi Zvi 
XP sp3, AMD Athlon 64 X2 Dual Core Processor 3800+, 2.0 GHz 
2GB DDR2 RAM  FA-101
Sonar 8.5  Producer Edition 32bit
Kurzweil K2661 (+Stereo Dynamic Piano ROM)

Well, I finally found something that worked for me: I got a USB-based audio interface (Focusrite Saffire 6).  I spent ALL DAY today making music and no time wrestling with Sonar/Windows/Drivers/etc.  I almost forgot what that was like!

The meter says CPU1 is still doing most of the work, but it's at around 20% rather than 50%.  Most important: no clicks, pops, dropouts, crashes or handfuls of hair!

For what it's worth, my advice to others having this problem is if you're using a Windows computer (a laptop in particular) with a Firewire interface (a Presonus Firebox in particular) -- check that out first.  I would have saved myself MONTHS of headaches had I done so. 

Now I'm going to go find a productive use for my Firebox.  Doorstop?  Paperweight?  Scrap metal??  The possibilities are endless!

PS - the Saffire 6, so far, is great.  Excellent sound, stable, flexible @48K/24-bit/7ms latency ASIO.  USB 1.1 is not an issue, which was my biggest fear.  My only quibble is the headphone amp is a little weak (a function of the limited USB bus power, no doubt) ...

Hi


I did few stuff and one of them must have worked... 
(I got XP service pack 3 , AMD processor and firewire device)

1. updated my AMD cpu driver.
2. Installed a program called dual-core optimizer from AMD
3. in system->advanced->performance->settings->advanced-> priority for background services

4. download an XP hotfix called KB955408


Now when activating the multi-thread option in sonar, the cpu bar is relaxed :)

sagizvi3. in system->advanced->performance->settings->advanced-> priority for background services

I'd undo that one, and see if there is any change. None other than the CTO of Cakewalk, Noel Borthwick, recommends against this tweak, and my personal experience with trying it on several different machines ranged from neutral to disastrous.

Has anyone actually heard back from Cakewalk on this specific issue? It's been a few weeks since the OP was going to call.

Just a-wonderin'....

brundlefly

sagizvi
3. in system->advanced->performance->settings->advanced-> priority for background services

I'd undo that one, and see if there is any change. None other than the CTO of Cakewalk, Noel Borthwick, recommends against this tweak, and my personal experience with trying it on several different machines ranged from neutral to disastrous.

I did undo that,  and everything is still working fine.
Cakewalk support also noted i should change a value in the registry that has something to do with my firewire speed.

[font="arial, sans-serif; line-height: normal; font-size: 13px; border-collapse: collapse; "]HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\PCI\hardware_ID\instance_ID\device parameters\sid speed



To sum it up, The cpu meter is fine (in my case , XP sp3, AMD dual core cpu, sonar procedure 8.5)
meaning my machine is able to process the audio buffer effectively .

1. installed microsoft hotfix for XP sp3 - http://support.microsoft.com/kb/955408/en-us 

2. updated the registry change
3. updated the amd cpu driver

planetearth


Has anyone actually heard back from Cakewalk on this specific issue? It's been a few weeks since the OP was going to call.

Just a-wonderin'....

I'm definitely curious about this as well. It seems running a kind of network based system creates this cpu usage (buffering issue) in Sonar that's not reflected in windows cpu monitoring. At the moment I'm beta testing a networked platform for a plugin in which other beta testers of other DAWs have reported success while I'm getting high readings in Sonar, for example with one instance of the plugin, while windows monitor reports barely 1%. The other testers' DAWs, needless to say, are reflecting exactly what windows reflects on their systems.
 
 
Vista 64, Sonar 64 i7 920

Well Cake have solved the problem for us by introducing Sonar X1/2/3.

At a cost it seems.

Sod this, I`m off for good.

ivanSC


Well Cake have solved the problem for us by introducing Sonar X1/2/3.

At a cost it seems.

Sod this, I`m off for good.

ivan, what do you mean "solved the problem"? Or, are you being sarcastic?
If you aren't being sarcastic, you have information that specifically implicates this fix in the new X1?

In the UK, sense of humor transplants are offered free on the National health.
Sadly, this was my tongue in cheek way of saying I have given up on Cakewalk, after many years and many dollars.

I find it quite sad that I was unable to get a resolution of the assorted CPU hit and Kelloggs Rice Crispies sound effects that have plagued me under win7 64 with sonar 32 AND 64 bit.

Members on here have at various times put forth sterling efforts to help but to no avail & since Cakewalk appear to have decided to ignore all the reported cpu spiking & associated problems and will undoubtedly now be telling us we need to upgrade to X1/2/3 and all our troubles will be over.
Somehow I doubt it, which is why I am gone.
I`ll drop by from time to time and visit & who knows?
If the audio engine etc get the revamp they deserve I may spend some more money with Cake in the future.

ivanSC


In the UK, sense of humor transplants are offered free on the National health.
Sadly, this was my tongue in cheek way of saying I have given up on Cakewalk, after many years and many dollars.

I find it quite sad that I was unable to get a resolution of the assorted CPU hit and Kelloggs Rice Crispies sound effects that have plagued me under win7 64 with sonar 32 AND 64 bit.

Members on here have at various times put forth sterling efforts to help but to no avail & since Cakewalk appear to have decided to ignore all the reported cpu spiking & associated problems and will undoubtedly now be telling us we need to upgrade to X1/2/3 and all our troubles will be over.
Somehow I doubt it, which is why I am gone.
I`ll drop by from time to time and visit & who knows?
If the audio engine etc get the revamp they deserve I may spend some more money with Cake in the future.

Ahh okay, well that's what I initially suspected but then good faith got the best of me! For me, it's this audio buffering CPU hit issue within a networked system. Otherwise, everything else is okay. I have to agree with you though that if this issue was properly addressed, I'm sure it would've been a highlight within listing "fixes" and/or features. I'm still scratching my head wondering why there is no demo to actually test for ourselves.

Prolly afraid we will realise ahead of time that they havent sorted the underlying stuff out..... 
Sorry.
That is a little unfair & I should keep my mouth shut.
Plenty of other people on here are reporting no probs with Win7 and Sonar on multicore machines.
Guess I got unlucky or I am dumb and missing something obvious?

          A very excellent discussion of a difficult problem. My apologies as I don't mean to beat a dead horse, but I only now discovered this thread which impacts directly upon my own work, quite heavily. In fact my problem is exactly the same as BenjaminCharles. As can be seen in my signature, I have sufficient hardware to run the program with a Q9650 Quad Core, 8 Gb RAM, 3 X-25M 160 Gb SSD's, running Windows 7 x64 and SONAR 8.5.3 x64 with the OS tweaked down completely to only the bare services. I do not run anything on this machine except SONAR and the synths. My sound card is a Profire 610 Firewire. I have read through the suggestions and the responses that BenjaminCharles has done, and all of these same tweaks that he has on his setup is the same as mine, except I use the ASIO drivers which come with the Profire 610 ( however, I do not believe they are an issue). 
  
          Like BenjaminCharles, I am a very heavy MIDI track intense composer, presently working on an animated film. I am relatively new to SONAR only having worked with it for about 2 years now, but I feel I know it well enough. I am Pro Tools certified, and have worked with computers for close to 30 years. I have built my own platforms for the last 15 years. 
  
         My problem is exactly like BenjaminCharles in that with any relatively intense degree of use of synths and instrument tracks, the playback starts to crackle, pop, and drops out. I am running full orchestral scores using EWQLSO Platinum, running 50 to 60 tracks (sometimes more) at a time, every one of them an instrument track with a synth assigned. Virtually all of them are EWQLSO with a couple of DimPro thrown in for certain effects. All the tracks have one, and on occasion two plugins. Like BenjaminCharles, SONAR actually works great. It allows me to compose as I want to compose. It does not crash or cause any problems with these large orchestral scores. When I export the final files, including full mixes, these files are fine on playback. Those are no problem. 
 
          But it's on playback that I cannot get the program to give me proper audio output without any blemishes, exactly as BC describes. When I first load up SONAR as a blank screen, there is no CPU activity of note. As soon as I load one of my heavy 50 to 60 synth laden projects in, the CPU activity goes up to about 25%, and that's without doing anything. The project is loaded, but just sitting there, hogging up CPU resources. I wonder why, when the program isn't doing anything. Remarkably, the Task Manager meter registers the same. When I play the project in real time, the CPU usage, both on SONAR and in Task Manager reflect each other and will start to max out heavily in the 60% to 80% level identically in all four cores, on very vigorous passages. Even quiet passages still register about 50%. 
  
         Like BC, I have tweaked aud.ini, the OS, and tried every other suggestion made here, and I did read through every one of them in this thread except trying the 32 bit version of SONAR. The problem with that suggestion is that it limits you to 4 Gb RAM as a 32 bit program, and loading all the sound samples of EWQLSO into RAM really gobbles it up (Some of the brass can have as many as several hundred individual sound files and take up as much as 200 Mb of RAM for a single instrument), so I felt I needed more RAM, thus a 64 bit platform, but it sounds like others have tried the 32 bit version and it didn't work. 
  
          Some people have weighed in feeling that they've had no problem with heavy track laden SONAR projects with lots of plugins. I don't think that would present a problem for SONAR so much. The specific stressor here, I believe, is using SONAR to lay down heavy MIDI intensive, multiple synth projects like a full virtual orchestra as BC and I are trying to do. Now others have had similar problems, and I'm sure the problem is still SONAR (And I am not knocking SONAR. I love the program as BC does, but not in this particular respect), but my point is the particular use of heavy multiple MIDI'ed instrument tracks seem to pose a particularly vexing  problem for this DAW program. I am in full agreement with BC on this. 
  
          In terms of fixing the problem, I will be soon trying to do that by upgrading to SONAR X1 ( just in case they managed to do something to help the problem, but I'm not holding my breath....), but also I will be buildng a new machine, basically a 12 core monster with SSD's and at least 16b RAM. I am curious to see if SONAR will utilize all of those cores. The RAM and SSD's should not give it any problem, but I have a sneaky suspicion that because of the way SONAR is programmed, I will still have the same Rice Krispy problem in the playback. 
  
         In the meantime, I am interested in using BenjaminCharles' solution of Rewiring REASON into SONAR. I have heard of the program, and briefly looked at it, but I am not familiar with it. But I will learn it if it will solve this headache. I would like to ask BenjaminCharles how much more difficult is it to have to use this as a go-between program in SONAR rather than injecting the synths directly as he has previously done. Also, if you wouldn't mind, BC, could you briefly outline how you did that. Thanks so much. 
 
Jeriddian

The rewire only works with the 32bit as far as I know. 

With the EW I have found that turning off all of the built in reverbs until I am ready to freeze the synth prevents a lot of drop outs, crackles and pops.  The last couple Play updates helped but I still have to do that with some large projects. 

My problem is exactly like BenjaminCharles in that with any relatively intense degree of use of synths and instrument tracks, the playback starts to crackle, pop, and drops out. I am running full orchestral scores using EWQLSO Platinum, running 50 to 60 tracks (sometimes more) at a time, every one of them an instrument track with a synth assigned. Virtually all of them are EWQLSO with a couple of DimPro thrown in for certain effects. All the tracks have one, and on occasion two plugins.

 
This sounds like a much heavier load than anything Benjamincharles described, and it doesn't surprise me that you are encounteirng CPU limitations. It was clear that BenjaminCharles was getting less than an acceptable level of performance. That's not clear at all in your case.
 
It seems like you expect to get something for nothing in terms of synthesis and DSP. It sounds to me like you just need to start freezing some finished tracks, and get on with it.

To Lorneyb2,
 
Thanks very much for your input. I am disappointed that REASON will only work in 32 bit. But you also have a very good point about the reverbs in PLAY. I do not have them turned off. That will mean I have to put the reverb in SONAR of course, but actually that will likely be better in the end.
 
To Brundlefly,
 
I thought my load was a little heavier than what BenjaminCharles has, although I didn't think it was a huge difference, however I see your point. I would like to ask what you mean about getting something for nothing in terms of synthesis and DSP, but also you have a very good point about freezing the finished tracks. I hadn't been doing that, mainly out of some laziness to be honest. But I do need to go back and try that out.
 
Thanks, guys, I appreciate it.
 
 

Thanks very much for your input. I am disappointed that REASON will only work in 32 bit. But you also have a very good point about the reverbs in PLAY. I do not have them turned off. That will mean I have to put the reverb in SONAR of course, but actually that will likely be better in the end.

PLAY has its share of problems, but its on-board reverb is meant to conserve processor use, actually. You can use it "globally"on all the instruments/outputs, which helps add to the "realism" of all the instruments playing in the same space. (If you're using individual reverbs on each channel in PLAY, then yes, you're asking for trouble.) Further, the reverbs in PLAY are actually good, convolution-based 'verbs. If you turn them off in PLAY, you'd have to add a buss in SONAR, route your PLAY outputs to that, and then add a similar convolution-based 'verb to it. I'm not sure that will save you any CPU cycles, but if you're willing to test it, I'd be very interested in the results.

That said, with the number of tracks you're using, you're probably going to bump your head on the limitations of something, somewhere, and freezing your tracks is probably a good idea, anyway.

Unless you use something like Reverberate LE (a convolution-based 'verb that taps the power of the graphics processor in NVIDIA video cards), you're still going to be tying up CPU cycles.

I'm still wondering what happened to BenjaminCharles and his call to Cakewalk support on this issue. He never reported back, and it's been months since he said he'd call them. Should we send out a rescue party?

Steve

The likely cause for the Play problem with reverbs on is DPC handling(see Wiki reference for explanation http://en.wikipedia.org/wiki/Deferred_Procedure_Call
 
 I am not suggesting not using the built in reverbs but to apply or turn them on as you freeze the tracks or do final mixdown.

That link to Wikipedia doesn't really go anywhere. Wikipedia doesn't have an entry for "Deferred Procedure Call".

Steve

jeridianI would like to ask what you mean about getting something for nothing in terms of synthesis and DSP

I mean do you really expect to be able to run 80+ instrument tracks with independent synth voices and effects, and not run into load problems? Synthesis and DSP use major horsepower. I wouldn't even dream of trying to run that kind of load on my Q9550, except possibly at very high latencies.

What buffer size are you typically running?

This is a Sonar problem plain and simple.....
I load up Ivory II, do NOTHING and it's sitting at 25 percent CPU.
Take a look at my sig and you will see I have a pretty decent system.
Nuendo and Reaper barely move the meter.

So what's going on here?

And if that's not bad enough, why can't I import some mp3 files into Sonar?
I have many 192 bit files that when I try to import them into Sonar I get "Out Of Memory" errors.
No DRM, nothing weird with them that I am aware of.

Worse yet, if I try and drag them to an empty Sonar screen, I get a Windows Explorer failure message pointing to Sonar.

I've looked at the forums via search and the solution seems to be convert to wave first.

Unacceptable.

Reaper, Audacity, Nuendo have ZERO PROBLEMS importing these same exact files.
They are also uploaded to the web and I have had not a single complaint about playing them.

Maybe it's a Windows 7 64 failure, I don't know but I've seen others in the forums with the same problem and it always seems to get minimized.

I'm willing to listen and be told what I am doing wrong and get my spanking but I don't see anything obvious.

wormser

This is a Sonar problem plain and simple.....
I load up Ivory II, do NOTHING and it's sitting at 25 percent CPU.

Just because you do nothing doesn't mean nothing is going on...
I haven't used it but maybe Ivory is doing something. Doesn't seem so "plain and simple" to me.

wormser

And if that's not bad enough, why can't I import some mp3 files into Sonar?
I have many 192 bit files that when I try to import them into Sonar I get "Out Of Memory" errors.

Sounds like you have options set to convert imported audio. Other apps may import audio exactly the way they are but Sonar has options to convert on import. If set, you could have Sonar import a 192k mp3 to 64 bit / 192 kHz wav file! Wouldn't take too many of these to run out of memory...

planetearth


That link to Wikipedia doesn't really go anywhere. Wikipedia doesn't have an entry for "Deferred Procedure Call".

Steve

Here is the info from Wiki
Deferred Procedure Call From Wikipedia, the free encyclopedia
Jump to: navigation, search
A Deferred Procedure Call (DPC) is a Microsoft Windows operating system mechanism which allows high-priority tasks (e.g. an interrupt handler) to defer required but lower-priority tasks for later execution. This permits device drivers and other low-level event consumers to perform the high-priority part of their processing quickly, and schedule non-critical additional processing for execution at a lower priority.
DPCs are implemented by DPC objects which are created and initialized by the kernel when a device driver or some other kernel mode program issues requests for DPC. The DPC request is then added to the end of a DPC queue. Each processor has a separate DPC queue. DPCs have three priority levels: low, medium and high. By default, all DPCs are set to medium priority. When the processor drops to an IRQL (interrupt request level) of Dispatch/DPC level, it checks the DPC queue for any pending DPCs and executes them until the queue is empty or some other interrupt with a higher IRQL occurs.
For example, when the clock interrupt is generated, the clock interrupt handler generally increments the counter of the current thread to calculate the total execution time of that thread, and decrements its quantum time remaining by 1. When the counter drops to zero, the thread scheduler has to be invoked to choose the next thread to be executed on that processor and dispatcher to perform a context switch. Since the clock interrupt occurs at a much higher IRQL, it will be desirable to perform this thread dispatching which is a less critical task at a later time when the processor's IRQL drops. So the clock interrupt handler requests a DPC object and adds it to the end of the DPC queue which will process the dispatching when the processor's IRQL drops to DPC/Dispatch level.
When working with streaming audio or video that uses interrupts, DPCs are used to process the audio in each buffer as they stream in. If another DPC (from a poorly-written driver) takes too long and another interrupt generates a new buffer of data, before the first one can be processed, a drop-out results.[1]

n0rd

wormser

This is a Sonar problem plain and simple.....
I load up Ivory II, do NOTHING and it's sitting at 25 percent CPU.

Just because you do nothing doesn't mean nothing is going on...
I haven't used it but maybe Ivory is doing something. Doesn't seem so "plain and simple" to me.

wormser

And if that's not bad enough, why can't I import some mp3 files into Sonar?
I have many 192 bit files that when I try to import them into Sonar I get "Out Of Memory" errors.

Sounds like you have options set to convert imported audio. Other apps may import audio exactly the way they are but Sonar has options to convert on import. If set, you could have Sonar import a 192k mp3 to 64 bit / 192 kHz wav file! Wouldn't take too many of these to run out of memory...

Of course "something" is going on even when the program, Ivory II is just loaded.
The question is, why does it take Sonar 25 percent of my i7 to do it where Reaper and Nuendo barely move the meter.

As for mp3 import problem, doesn't matter if I have it set to convert or use the native format.
Same thing.
Drag/drop, do it from the menu etc.

Bang.... Out of memory error.
Not sure why.

This is a Sonar problem plain and simple.....

"plain and simple" may be more than a little naive. If it were either plain or simple, you wouldn't be here seeking advice because you'd have already solved the problem.

Why a VSTi chews up CPU cycles while idling is a question for its vendor to answer. Lots of instruments do that, and it's something the plugin developer could have dealt with but chose not to. Sounds like laziness on the vendor's part, but in truth that idle CPU usage means nothing. It causes no problems, does not add to the CPU usage during playback - it's just a trivial annoyance.

As for your out-of-memory errors attempting to import MP3s, have you tried importing them via File -> Import rather than drag 'n drop? I ask because in 6 years I have never once had an import fail, but I never drag files into a project.

bitflipper: I would agree except that Sonar is the only host that does this. All the other hosts reflect pretty much what Windows 7 task manager shows. That's the first thing Synthogy is going to bring up. Of course Cakewalk is going to say it's an Ivory II problem because other Vsti don't behave like this.

As for the mp3, yes I did try via file menu as I said above.
No luck.

I have to narrow it down a little more wrt the mp3 problem.
I'm gonna check the files and see what's going on.

They all open fine in Reaper, Nuendo, Audacity and Soundforge.

Man.. I sure am glad I am still using vista 64 bit..lol.. All these problems and each one the operating system is windows 7... maybe I am being to "simple" but... looks like a common thread here.
I don't have a monster of a machine, 8 gigs of memory, dual core pentium... but I start to max out with audio and midi tracks totaling around 30. then I start to get some crackles maybe.

I have never ever on any system I have used ever had any trouble importing mp3's. Never tried the drag and drop method, I don't see why anyone would with sonar, it takes up the screen, much easier to just do it thru the file method.

as for the meter, it is nice to look at, but I don't pay much attention to it, now the disk meter I do, that could cause some problems if the usage from disk is high.. but the cpu meter, no big deal. But for clarification, the highest I have ever noticed it go, is possibly 21 percent.. normally it hovers around 4 or 5 percent.

Motto of the story... to me it sounds like something with windows 7. It is the latest and greatest from uncle bill, and true to form, it has issues. Just like all the other releases of windows.

Guitarman1


Man.. I sure am glad I am still using vista 64 bit..lol.. All these problems and each one the operating system is windows 7... maybe I am being to "simple" but... looks like a common thread here.
I don't have a monster of a machine, 8 gigs of memory, dual core pentium... but I start to max out with audio and midi tracks totaling around 30. then I start to get some crackles maybe.

I have never ever on any system I have used ever had any trouble importing mp3's. Never tried the drag and drop method, I don't see why anyone would with sonar, it takes up the screen, much easier to just do it thru the file method.

as for the meter, it is nice to look at, but I don't pay much attention to it, now the disk meter I do, that could cause some problems if the usage from disk is high.. but the cpu meter, no big deal. But for clarification, the highest I have ever noticed it go, is possibly 21 percent.. normally it hovers around 4 or 5 percent.

Motto of the story... to me it sounds like something with windows 7. It is the latest and greatest from uncle bill, and true to form, it has issues. Just like all the other releases of windows.

 
Not necessarily...Vista 64 here and as I described my "special" situation of higher than usual CPU within Sonar is when trying a networked plugin in which as wormser mentioned, behaves fine in other DAW's and reflect what Windows reflect without affecting performance. Now, I say "special" because in all other situations I find myself in working, Sonar behaves just fine. But these occasional situations of high CPU (as some mentioned, Sonar's audio buffering) need to be addressed as other DAW's do not reflect the same behavior.

All the other hosts reflect pretty much what Windows 7 task manager shows.

Could it be that other hosts aren't showing the same thing?

There is no direct correlation between SONAR's CPU meter and Windows Task Manager's CPU usage display. They are simply not displaying the same information, and I wouldn't expect them to have any correlation.

I suppose the real problem is that SONAR's CPU meter shouldn't really be called that, since it's really not really a CPU meter. I don't know what else they could have called it, though, that would have 3 letters and fit into the status bar.

[PlanetEarth] PLAY has its share of problems, but its on-board reverb is meant to conserve processor use, actually. You can use it "globally"on all the instruments/outputs, which helps add to the "realism" of all the instruments playing in the same space. (If you're using individual reverbs on each channel in PLAY, then yes, you're asking for trouble.) Further, the reverbs in PLAY are actually good, convolution-based 'verbs. If you turn them off in PLAY, you'd have to add a buss in SONAR, route your PLAY outputs to that, and then add a similar convolution-based 'verb to it. I'm not sure that will save you any CPU cycles, but if you're willing to test it, I'd be very interested in the results.

That said, with the number of tracks you're using, you're probably going to bump your head on the limitations of something, somewhere, and freezing your tracks is probably a good idea, anyway.
 
I tried it both ways, actually. It seemed to actually do better and sound better if I kept the PLAY on-board reverb the way I had it, so I will kepe it that way. However, I did solve the problem more or less by simply freezing the Brass tracks. All hiss, pop, and dropouts went away. I brought the Brass synths back in, the hiss, pop, and dropout reappeared. Once I froze the Brass again, the problem disappeared again, so that does solve the problem more or less in that regard. I'm sure all I have to do is freeze sufficient tracks of any kind to take care of the problem in the future. So the problem was simply I was being lazy and not freezing the tracks.
 
[lorneyb2]  I am not suggesting not using the built in reverbs but to apply or turn them on as you freeze the tracks or do final mixdown.

That will be useful in some of my more extreme projects, I think. Fortunately, so far, just freezing some of the synths is sufficient.
 
[brundlefly] I mean do you really expect to be able to run 80+ instrument tracks with independent synth voices and effects, and not run into load problems? Synthesis and DSP use major horsepower. I wouldn't even dream of trying to run that kind of load on my Q9550, except possibly at very high latencies.

What buffer size are you typically running?
 
You're right. That load problem was exactly what I was worried about when I set out to do this in the first place, which is why I bult the most powerful machine I could build at the time to handle it. My laptop was custom built and was the most powerful one I could get fitted with SSD's when I got it almost two years ago. It has worked very well for me overall. This problem with the playback is really the only problem it has given me in all this time. As I use the ASIO drivers from my Profire 610, my latency is set by them automatically and typically is reported to be something around 6.3 msecs (I'm not in front of that computer right at the moment). It doesn't cause me hardly any problem when I add in my MIDI tracks on the piano keyboard. As for buffers, I used the standard SONAR default of 256 on record and 1024 on playback, although I have tried 2048, though this changes things very little. Fortunately, the computer has handled everything else well. I have the Q9650 at 3.0 Ghz. So I would think your Q9550 being pretty much the same processor only at a slightly lower speed of 2.83 Ghz should be able to handle these kind of large projects.
 
[bitflipper] Why a VSTi chews up CPU cycles while idling is a question for its vendor to answer. Lots of instruments do that, and it's something the plugin developer could have dealt with but chose not to. Sounds like laziness on the vendor's part, but in truth that idle CPU usage means nothing. It causes no problems, does not add to the CPU usage during playback - it's just a trivial annoyance.
 
[wormser] bitflipper: I would agree except that Sonar is the only host that does this. All the other hosts reflect pretty much what Windows 7 task manager shows. That's the first thing Synthogy is going to bring up. Of course Cakewalk is going to say it's an Ivory II problem because other Vsti don't behave like this.

I must say that it seems to me that there is a problem specifically with SONAR programming regarding this issue. While bitflipper's point in that there is no relationship between the the CPU meters of SONAR and Task manager is reasonable and certainly makes sense to me, still I find that they both behave exactly the same in all conditions on my machine when I run SONAR. And as I noted, when SONAR is pulled up empty of all projects, there is no activity to speak of. Once I pull in a project with 50 synths, it will idle at about 25% on both meters. That may be indeed a problem the vendors should address in any case. However, I think it has become clear that SONAR definitely has a higher CPU usage in this particular scenario than the other DAW's mentioned. I grant I haven't tried the other DAW's out (except Protools, but I don't use that for music composition), but reading from the responses in this thread, I think the anecdotal reports are pretty strong.
 
[Guitarman1] Man.. I sure am glad I am still using vista 64 bit..lol.. All these problems and each one the operating system is windows 7... maybe I am being to "simple" but... looks like a common thread here.
I don't have a monster of a machine, 8 gigs of memory, dual core pentium... but I start to max out with audio and midi tracks totaling around 30. then I start to get some crackles maybe.
 
[Transcending] Not necessarily...Vista 64 here and as I described my "special" situation of higher than usual CPU within Sonar is when trying a networked plugin in which as wormser mentioned, behaves fine in other DAW's and reflect what Windows reflect without affecting performance. Now, I say "special" because in all other situations I find myself in working, Sonar behaves just fine. But these occasional situations of high CPU (as some mentioned, Sonar's audio buffering) need to be addressed as other DAW's do not reflect the same behavior.
 
I must agree with Transcending in this. When I first started this project, I was working in Vista x64, and later upgraded the OS to Windows 7 x64. The problems with the dropouts were no different with either platform.
 
[bitflipper] Could it be that other hosts aren't showing the same thing?

There is no direct correlation between SONAR's CPU meter and Windows Task Manager's CPU usage display. They are simply not displaying the same information, and I wouldn't expect them to have any correlation.

This is also a good point. But it would seem that the reports in this thread from those who have looked at this issue is that in the Task manager, the CPU meter was still low in the other DAW's, yet still high with SONAR, and the Task Manager meter had to be measuring the same thing in all cases. Having looked into this a little more, I think you are right that there is no correlation between the two CPU meters. However, the physical symptoms reported are still the same in which dropouts were being reported in SONAR but not in REASON or the other DAW's. Maybe looking at the CPU usage is not the right place to look for the problem, but it does seem fairly logical, and I can't think of an another factor offhand that would apply. It does seem to me that SONAR (and probably all the DAW's) has an ordered priority in which, of all the processing tasks that have to be done, playback is the least important and becomes the first to be sacrificed in the case of lack of processing power. Maybe that's an obvious statement (or wrong), but it does highlight that it is the first problem to appear when projects get more and more complicated.
 
Thanks, guys, I appreciate the input. I'm getting a better picture of how this is going now.
 
 
 

 

bitflipper

All the other hosts reflect pretty much what Windows 7 task manager shows.

Could it be that other hosts aren't showing the same thing?

There is no direct correlation between SONAR's CPU meter and Windows Task Manager's CPU usage display. They are simply not displaying the same information, and I wouldn't expect them to have any correlation.

I suppose the real problem is that SONAR's CPU meter shouldn't really be called that, since it's really not really a CPU meter. I don't know what else they could have called it, though, that would have 3 letters and fit into the status bar.

I think understanding what to call it is more a matter of semantics - in this case. This is because no matter what you want to call it,
even if they are not correlated, Sonar's performance suffers and falls short where others don't for identical processing, whether it's a particular VSTi or a simple networked situation as in my case. That's the critical aspect here. So, whatever "it" (Sonar CPU) is, doesn't matter as much as the impact it is having on performance.

If you read Noel Borthwick's thread in the sticky area about the "Fine Print" yoou'll learn that the CPU meter in SONAR is just measurng the the processor power being used to prepare, fill and empty a buffer of data. Noel goes into great detail to explain why this is more accurate.

To those of you who have problems on playback are you increasing your buffer sizes?

I, like many of us have 2 different settings, small buffers for recording and larger buffers for mixing/playback

there is a point at which you have to start trading CPU use for being able to empty buffers quickly enough so you don't get crackling ooon plyback. As bitflipper said maybe you need to start freezing tracks to provide some relief.
Hope I explained it well enough. I'm a layman not a technician.

mudgel


If you read Noel Borthwick's thread in the sticky area about the "Fine Print" yoou'll learn that the CPU meter in SONAR is just measurng the the processor power being used to prepare, fill and empty a buffer of data. Noel goes into great detail to explain why this is more accurate.

To those of you who have problems on playback are you increasing your buffer sizes?

I, like many of us have 2 different settings, small buffers for recording and larger buffers for mixing/playback

there is a point at which you have to start trading CPU use for being able to empty buffers quickly enough so you don't get crackling ooon plyback. As bitflipper said maybe you need to start freezing tracks to provide some relief.
Hope I explained it well enough. I'm a layman not a technician.

Yes I did read the thread.

It doesn't matter  what the processor power is being used for, it's a matter of 25 percent of the processor power being used for ONE TRACK not even playing or recording.
There is only one track so freezing is not an option :)

This is on an i7 950 with 6GB although I had almost identical results with my Quad Q9400.

I don't seem to be getting any problems if i load up the project, but still it's unsettling to see this especially on a powerful system. BTW it did the same thing when using my Alesis MasterControl FW as the audio/MIDI device as well so it's not related to drivers, at least not for the interfaces.

I suspect it's a combination of things both from Sonar and Ivory II because no other DAW I have tried has this problem with Ivory II AND not other Vsti that I have tried with Sonar has this behavior with Sonar.
Although I have read of other people having problems like this with some other VSTi.

As for the mp3 problem, I have made progress.
It seems that mp3 rendered FROM Reaper don't want to open in Sonar for some reason.
I tried some other mp3 of general music stuff and they all open in Sonar fine.
Also mp3 rendered FROM Sonar also open fine in Sonar, and Reaper as well.

Interesting since both Reaper and Sonar are using LAME as the encoder.
I have to investigate further but a quick look doesn't show anything odd and I have tried playing with the bit depths with no luck.

Have to look into this one (mp3) a little more, but I would say Sonar is off the hook for the moment. Maybe a tagging problem or something like that.