Over the holidays I was working on an orchestral mockup and really pushing my system to its limits. To avoid pops and crackles I had to increase my buffer to 512, and the resulting latency was bad enough that it was throwing my ability to play in time. I started doing things like when I was working on the brass I would mute the strings and winds and set my buffer to 128 or 256, work on the section, then put the buffer back to 512 before unmuting the other choirs. It worked… But it was very frustrating.
 
Partly due to this experience I started giving Cubase a good hard look, and in fact picked up an education edition of Cubase Pro 8. There were a few factors motivating my curiosity, but one of the most intriguing to me was ASIO Guard, which essentially doubles or quadruples the latency of tracks that are not the active track (i.e. the one you are playing at the moment), so you can keep lower buffer settings on your sound card overall and get the same performance you would from higher buffer settings. Sure enough, after I went through the painstaking process of recreating my orchestral template in an unfamiliar program (and dealing with a few annoying Cubase bugs), I found that even at a buffer setting of 512 the exact same instruments were much snappier in Cubase. BUT… now I’m not sure that was the miraculous “ASIO Guard” or something else!
 
I decided to actually measure the problem, so in each program (64 bit versions) I set up a single instance of Kontakt with a UREI click panned hard right. I also played a sidestick sound from my master keyboard (local control on) panned hard left and recorded the output of both to a stereo track, which I brought into Sound Forge for analysis, measuring the time between the onset of the sidestick on the left channel and the UREI click on the right. I should note that my reported latency for both programs (which I think is handled by the driver) was the same: 12 msec and change for input, 13 and change for output, totaling ~26 msec roundtrip.
 
I don’t know if triggering samples requires the whole roundtrip time or not, but here’s what I found:

• Between the onset of the sidestick and the UREI click, Cubase averaged just less than 22 msec.
• Sonar averaged just over 55 msec (over 1/20^th of a second!).

The 22 msec latency is noticeable but not annoying… 55 msec is intolerable to play!
 
Does anybody have any clues as to why I’m seeing this fairly major discrepancy between the two programs, using the same hardware and same 3^rd party plug-ins? Is there a way of getting Sonar to the same performance level as Cubase?
 
Some info about my system:

• Intel i7ProPlus @3.15GHz
• 12 GB RAM
• Windows 7 Professional (64-bit)
• PreSonus StudioLive 16.4.2 mixer/soundcard
• Sonar X3e (both 32-bit and 64-bit installed)
• Cubase Pro 8 (64-bit)

 
Thanks in  advance for your help,
-Jake Winkler

I run tracking/recording with an ASIO Buffer Size of 128, and get a total roundtrip latency of 9.7 milliseconds, so I am not sure why you are running with such a high value with your system.
 
If you have a bunch of tracks that are data-stable, meaning the midi data is captured and reasonably not being edited at the moment, why not freeze those tracks, which would free up a bunch of resources in Sonar, giving you a similar result to what you were getting with that ASIO Save mode.
 
In addition, I would look at why your latency values are so high.  If you are running with a bunch of effects on while trying to record other tracks, you are going to drive your system quite hard.
 
Many folks either delay putting effects onto tracks until they finish tracking and are ready to move on to mixing, OR they freeze tracks when things start to bog down, OR they bypass all effects by hitting the 'E' key on their computer keyboard (toggles all effects off/on), to free up resources.
 
In addition, if you are running a laptop, be careful with your Wi-Fi adapter/drivers, that can be problematic - lots of folks turn off or disable their Wi-Fi adapter prior to launching a Sonar session, then turn on or enable it when done with Sonar.  (that can greatly reduce induced DPC Latency, which will benefit your streaming audio in Sonar).
 
Bob Bone
 

As I said, it's a large orchestral template, and I was getting pops and clicks at lower buffer settings. It's not a laptop, it's a desktop (a StudioCat DAW put together by Jim Roseberry), though admittedly a few years old now. When I work on smaller projects... rock tunes or smaller scale orchestral stuff... I can use a buffer size of 128 with no problems whatsoever.
 
I'm not interested in more workarounds, though. Freezing would work... But in this case I'm also trying to work at a slower tempo as I play it in, so it would be a lot of slow back and forth with freezing and unfreezing. These are not "data stable" parts, as you call them. I typically sequence the lower strings first and work my way up through the orchestra, ~16-32 bars at a time.
 
For the sake of argument, let's assume that I do in fact need my buffer at 512. The limiting factor seems to be my Cinematic Strings 2 library which causes glitches on fast runs if I set it any lower, even though it's on my fastest drive (an SSD).
 
Why am I seeing such noticeably poorer performance in Sonar than in Cubase under otherwise identical hardware settings and plug-ins? The only difference is that the tracks in Sonar have the ProChannel engaged.
 
Thanks!

As taken of your word, with all bearings being true, then your analysis shows an area where Cubase 8 outperforms Sonar X3e.
Competition is good. It is what drives better products for more money profits and boasting credentials. This can only drive Cake to do strive to do better.
Just that. Why not compare the latest version of Cubase to the latest version of Sonar.
Cakewalk has said they have used the newest programming coder, or whatever as described, which apparently has made Sonar 'the new' much snappier.  

Yes, I read a thread or two to that effect. I haven't taken the Platinum Plunge yet (I'm not thrilled with what I perceive to be a fairly steep price hike on upgrades), but knowing me I won't be able to resist for TOO long. Once I do I'll see whether Platinum fares any better...

I always track/record at 128 but Sonar has never behaved for me at less than 512 on playback. Don't know why. With lots of parts I even go to 1024, and I don't have a slouch system either.

I have a Jim Roseberry system (see my sig) and can run a half dozen instances of Kontakt running Kirk Hunter Strings, Chris Hein Horns, Omnisphere, Steven Slate Drums, Trilian, among others in Platinum. I can run at 32 samples with all of them frozen and feel no latency recording guitar through Axe Fx Ultra and listening via my monitors (not direct monitoring). My system is a 'few years old', too. Not sure if you're running fx like verb or other plugs that induce latency.

What's the point of low buffer settings if the software is going to whack up latency to deal with them? Lower latency is the only benefit of lower buffer settings.

I realise that's not the only, or even main, question in the thread, but it popped out at me.

I have't read the entire thread in excruciating detail, but I see no mention of Plugin Delay Compensation (PDC), which is the only reasonable explanation for the difference.
 
Given the symptoms, it is highly likely that somewhere in the SONAR project you have a plugin that uses a look-ahead buffer for processing that adds to the total buffering latency, and SONAR is automatically delaying the output of other tracks to sync with the delayed track/bus. This is PDC.
 
SONAR has a PDC override function that will disable this compensation on Input-monitored tracks so that you can rehearse/record real-time input to a track without being subject to this delay, but it would be best to hunt down the offending plugin, and swap it out for something that doesn't induce PDC.
 
Ordinary FX will not increase latency no matter how many you load up. At some point, the increasing load will just start causing pops/crackles due to dropped buffers, but the latency will remain the same until the audio engine drops out completely.