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

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

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?

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.

          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

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.

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

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

Steve

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.

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]

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.

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.

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.

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.

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.