External Insert takes 10% of CPU? (Verify?)

When I add an external insert to an FX bus (using a hardware reverb) I notice that it takes 10% of my processing.  One of my four cores jumps from 25% to about 50%.  Adds pops and clicks so I have to up the buffer size.
 
Is this normal?  What would cause an external insert to use so much processing?  This turns out to be more expensive than just using an ITB verb.

Cakewalk should FIRE your sorry A$$ for being dismissive of legitimate issues.  If you were just a random forum user I wouldn't care, but you are an employee of Gibson and you are acting unprofessionally.
 
I have the image ready to post, showing how adding a single External Insert robbed 10% of processing, and then I remembered.. . .I HAVE OVER 200 POSTS AND I CANT POST IMAGES ON THE *&^% FORUM!
 
Let me know if you'd like it.  You are going to see it when I figure out how to post it. 

200bpm
Cakewalk should FIRE your sorry A$$ for being dismissive of legitimate issues. If you were just a random forum user I wouldn't care, but you are an employee of Gibson and you are acting unprofessionally.

 
Please read the following in its entirety.
 
"Dismissive" means "feeling or showing that something is unworthy of consideration." Obviously I felt AND showed it was worthy of consideration, because I took the time to run an experiment, insert 17 external inserts running four stereo pairs through effects (I didn't want to have to unpatch the other connections, and you mentioned only one insert anyway). I took screen shots both before and after adding the inserts, cropped them, and posted them. I did this because if there is a legitimate problem, I need to know about it, provide steps for Cakewalk to reproduce, and submit a bug report.
 
Many users have made significant contributions to an ever-more stable program by defining issues clearly and unambiguously, and providing steps to reproduce so that it's possible to confirm whether something is a legitimate SONAR-specific issue or not. As you rarely provide sufficient data, or even post in the appropriate forum dedicated to Problem Reports, then it is up to me and other users - the unpaid volunteers you call "apologists" and "PR people" - to try and reproduce your "bugs" on your behalf.
 
If you consider that behavior unprofessional, then I would dispute your understanding of the word "unprofessional." It is not my fault that despite trying, I cannot duplicate what you are experiencing with your system. Nor after searching, could I find any reference to it on the web or in these forums. If I cannot reproduce it, and if no one has encountered this problem before and suggested a fix, I cannot recommend a specific way to fix it.
 
I can help confirm SONAR-specific problems but rarely can I help people with system-specific problems because there are too many variables.
 

I have the image ready to post, showing how adding a single External Insert robbed 10% of processing, and then I remembered.. . .I HAVE OVER 200 POSTS AND I CANT POST IMAGES ON THE *&^% FORUM!
 
Let me know if you'd like it.  You are going to see it when I figure out how to post it.

I already told you how to post images. 
 
I don't deny that you are experiencing problems with your setup. I never did.
 
I am simply saying that based on the evidence I have found to this point, it is not a SONAR-specific problem, or I would experience it as well. Or at least someone else would. At best it involves SONAR's interaction with some element other users have not experienced, at least that we know about. It's also entirely possible you left out crucial data that might enable someone to reproduce it.
 
Also, I already posted a link, with a suggested fix, regarding the extent to which AMD graphics drivers can potentially degrade performance. This may or may not be a factor in this and other problems you experience, but it has solved many other "what could this possibly be" problems and is reversible, so there's no reason not to try it. I cannot force you to click on links I provide with suggestions on how to resolve your problems, but given the amount of time I have spent on your personal issues, considering me dismissive is not an opinion I think anyone other than you would hold.
 
I DO post threads about legitimate problems I have found, and ask for confirmation. Sometimes people CAN confirm and with our collective knowledge, Cakewalk has enough information to engineer a fix. If no one can confirm your problem, a fix will not be forthcoming because it is not possible for Cakewalk to solve a problem they cannot make exist. You have seen my results; perhaps we will hear from others that can confirm what I've experienced or what you have experienced. If the latter, then it may be possible to do analysis beyond "Here's a screen shot that shows there's a problem with my system."
 
Besides, Cakewalk can't fire me. I'm not a Cakewalk employee. Nor do I think your opinion is representative of the community.

When I insert 17 inserts nothing changes with respect to performance or power consumption. I cannot suggest how to fix a problem I cannot reproduce.

Well done John. Thanks Craig for all the wonderful help. I am sure it is very much appreciated by all.

I too thought that might be the case, but see post #8.  I tried to duplicate his results on a computer that's LESS capable. His is quad core, the one I tested is dual core and about a GHz slower (although it's Intel and not AMD, so I couldn't duplicate that part of the experiment. The desktop has AMD graphics, but with my driver fix that solved those various latency issues).
 
200 bpm, let me try to clarify what I mean about bug reporting. You say "I insert an external insert and the CPU consumption goes up. It is a bug." HOWEVER, when I insert an external insert, whether on a hot computer or a funky old one, the CPU consumption doesn't go up enough to be even slightly visible.
 
So, the logical conclusion is that simply inserting an external insert is NOT the problem. There is probably an "and" missing, like "If I insert an external insert AND the project is running at 192 kHz" or "If I insert an external insert AND there are AMD graphics drivers" or...something. But just inserting an external insert doesn't seem to be the source of the problem, or it would have caused a problem on one of the three computers on which I tested it.

Cool, Craig. I was rushing because I had been called to dinner and I think it might be possible that your post 8 came after I started composing my post (10). We were thinking the same thing (you were testing what I was thinking and showing it to be an insufficient explanation).
 
I'm not sure if I misunderstand, but it sounds like maybe you are suggesting fixes like these...
http://forum.cakewalk.com/Hey-People-Who-Know-About-Computers-Is-this-a-Fix-for-a-LOT-of-Sonar-Problems-m3086454.aspxi
 
Or something else computer specific? I'm not sure.

gswitz
 
I'm not sure if I misunderstand, but it sounds like maybe you are suggesting fixes like these...
http://forum.cakewalk.com/Hey-People-Who-Know-About-Computers-Is-this-a-Fix-for-a-LOT-of-Sonar-Problems-m3086454.aspxi
 

Libraries can get out of sync, but it is the responsibility of the installer (InstallShield, etc.) to verify that the libraries are present and of sufficient version, and if not to install them.  Libraries should be backwards compatible so that upgrading does not break the "contract" with older applications and Microsoft sufficiently regression tests their releases that I have high confidence that new distributions will not break Sonar.   I'm a Unix developer so don't know the intricaces of the Windows registry or COM+, but its possible that a reinstall could fix bad/missing registry keys.   However, I just reinstalled Sonar a few days ago trying to solve another bug, so its unlikely that this will fix it.
 
At the point where you are manually installing system libraries to get your software to work, that usually indicates an installer bug.  Undocumented workarounds are bugs even if some people have hacked the software to work or been conditioned to avoid actions that cause it to fail.

 Forget it  Bad post 

gswitz
Sorry, sounds like I grabbed the wrong link by what your saying. Oops. I meant to grab the link where grab talked about disabling unused audio devices in the device manager and somewhere else I forgot about already. Hold on... searching for the one I meant to post.
 
Yeah... I can't find it. I didn't mean to post the link about the C++ runtime.

It's this one. I had already referenced it in another 200 bpm thread. I doubt he tried it, but it made a huge difference with my AMD HD graphics card and drivers. Ditto making sure it always has the latest drivers, but more importantly, knowing how to roll back to previous driver versions when you find the new driver that gives 2 frames per second better performance with the game "Let's Kill Everybody" also kills the performance for audio streaming. Well, at least until the next driver update, in three weeks. Which might render something else unusable. 
 
Others have reported equally huge differences by eliminating a card's HD audio driver; some have reported no detectable difference. So this technique is not guaranteed, but it's free, reversible, takes two minutes to check out, and if it reduces your latency so much the better.
 
It has taken me years of bashing on this, and buying/rejecting several graphics cards, but at least some people realize I'm not kidding when I emphasize how much graphics performance affects DAWs.
 
But - we have another potentially valuable clue. A "fast gaming graphics card" can be one of the absolute worst choices for a computer that needs to stream multiple channels of audio in real time. Some of their drivers will literally block the CPU from doing anything until the card gets what it wants. Some nVidia cards are known to do this. I found the AMD HD audio driver to be a total pig and completely unnecessary. Starting a couple months ago (come to think of it, around the time of a driver update) I had become so frustrated with SONAR's latency/crashing issues on my desktop I was debating whether to use SONAR only on my less powerful laptop, where it nonetheless worked fine. Deleting that one driver meant I could keep the fanless graphics card and continue to use SONAR on my desktop, with better performance than I'd ever experienced before. (FYI AMD's Catalyst Control Center program usually crashes within 15 minutes of booting my computer, but that's a good thing because it seems to perform no useful function other than ask for CPU cycles.) 
 
I seem to recall something about SONAR being more graphics-intensive than some other programs, so it's more dependent on system graphics performance.
 
To add insult to injury, those who purchased PCI-based interfaces to get that extra ounce of performance compared to USB or FireWire and who use PCI-based graphics cards are at the mercy of drivers that hog the PCI bus, and tell the PCI audio card to just sit there and shut up while it takes over the bus for as long as it wants.
 
I can't help but think of this analogy for at least some of the problems 200 bpm describes. He's lost his keys, and he's sure he's lost them in the kitchen. So he keeps looking in the kitchen. Someone says "Hey, maybe they're in the living room" but he's sure he lost them in the kitchen, so he keeps looking there. Finally, after hours of frustration he gives up on finding the keys, goes into the living room to watch some TV, and...finds the keys fell in between pillows on the couch.
 
The only way I know of to get around Windows variability is to get something like a PC Audio Labs, Studio Cat, ADK, or other Windows computer integrated for music. Or you can get a Mac, although unfortunately that experience sure isn't what it used to be. Logic is probably more similar to SONAR than most other DAWs, even though it lacks several key SONAR features.

Craig,
The only problem with your analogy is that the last three times I lost the keys, they were never in the Living Room and two sets are still missing.
 
The computer performs the same with either on board video or graphics card.  This is not 1996, the vast majority of graphics cards play well with others.  This is a dedicated DAW which I have played some games on, but none are currently installed.  I got the video card so I could use three monitors.
 
I tested the Firewire interface vs the USB and I'm getting lower latency, better utilization with the firewire (was using the usb), however even with firewire adding inserts increases cpu.  
 
This mobo has a good firewire chipset and native PCI slots, and really low DPC latency, some of the reasons I have not upgraded.   This setup is at the lowest latency allowed with reported 3.7ms round trip latency.  I can obviously increase buffers but the surprising point is that simple audio routing, the External Inserts and the Channel Tools plugs, use significant cpu in sonar.
 
At higher buffer settings I am able to load up projects with 80+ instances of assorted plugs, many of them heavy.  This computer is enough for my needs; my concerns are more around operation at low latency and my disappointment that routing plugins use significant CPU.
 
 
 
 
 

The reported RTL (3.7ms) is the same with the USB, but cpu utilization is a bit higher (?), so I can load more instances at lowest latency using the firewire.  I am using the onboard usb2.0, but I also have a usb3.0 pcie card which may influence the usb in some negative way.
 
I'm using Firewire for a couple other reasons.  1) Less likelihood of usb bottleneck or interruptions from other devices.   2) When I direct connect my GT100 for online editing, I get a tiny ground loop noise when the UFX is connected via usb.
 
Yes, I am using the UFX for mix verb and mix bus compression.  I was going to use the External Insert, but routing the send out a stereo bus and using loopback accomplishes the same thing.  I have thought about doing the same with track compression and EQ, or using the UFX as an external mixer, but the Pro Channel is sufficiently lightweight that I can mix ITB.
 
What RTL is sonar reporting for your UCX?
 
 
 

Using a higher buffer setting decreases cpu utilization, but adding an external insert still shows a noticeable uptick.
 
The whole point of using an external insert is to offload processing, so this surprises me.

200bpm
The whole point of using an external insert is to offload processing, so this surprises me.

There may have been times when I would have seen the whole point as to provide a method to offload processing, but I haven't seen it that way for years. The main purpose is to use any external equipment. Consider re-amping. Or use of some hardware compressor. If the only purpose was offloading processing, I wouldn't need it at this point.
 
I'll bet you Mr. Craig Anderton uses external inserts pretty casually as do any number of other regular users.
 
For me the real value is that it auto calculates the latency offset through the external equipment and compensates the whole mix appropriately so that you don't have problems introduced by the round trip latency (exactly what would happen if you just send it to your outputs on your interface and then route it back in. Now, on your interface at lowest latency, I'm not sure you could hear it. If your track ended up 69 samples behind or something. idk who cares. In that case I'm suggesting that you are looping back inside your interface to take advantage of the fx processor in your interface.
 
For that matter, you could get 0 sample latency offset if you send out both the instrument mix and the one item for external fx, then loop them both back and re-record them together or mix them together in the interface before loopback and record the combined pair. idk. Just thinking. In other words, they'd both have the same new latency introduced which would mean it wouldn't matter.

Is the PC specified in your signature "AMD PhenomIIx4 @3.6, HP Pavillion DV7-7012nr" the machine you are experiencing problems with?
 
I ask as I note that it is a marketed as an Entertainment Notebook PC Product and I wondered how you changed the graphics card as indicated in earlier post.