Latency at buffer size of 512 is unacceptable... But NOT in competing product!

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

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!

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

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

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

Here's a couple of thoughts, and I use Cubase 7.5 as wells as sonar x3/platinum.  Some things seem better in either program - this is not a case where I've seen a noticeable difference.  
Enable cubase's version of the prochannel (the channel strip) with similar settings to sonar and see how it impacts your performance.  
Some things happen under the hood in cubase that you can control in sonar.  Some ideas - 
in preferences, select audio/config file and set extrapluginbufs to 32
 
In kontakt, if you have the ram, under options/memory increase the instrument preload buffer size.  This should definitely help with cinematic strings - it certainly helps my spitfire libraries when I'm using many of them. 

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

 I see an RME 9632 in your profile.  I think that makes a difference and it's a PCI device. 

Don't forget that ASIO Direct Monitoring thingy - Cubase support that, not sure about Sonar. And not sure about Presonus interface either - but something to check out maybe, both interface and daw need to support it.
 
It means audio can slip past any roundtrip inside daw, interface shortcut that for you.
So that is audio, not playing midi stuff which would need midi in and only audio out buffers delay.
 
Another note I made upgrading to Sonar 8 2010 or something, evaluating new interface for my new daw at the time.
 
I could run a demo project in Sonar, if it was 11 audio tracks, at 128 samples buffer - no crackles.
But inserting a synth, Dimension Pro, it crackled monitoring that at 128 samples - just playing a note.
Increasing buffer to 192 samples, DP played good too.
 
I created a fresh project, only one track with DP in it - same thing.
Need to increase to 192 - then fine.
 
So something is different in how Sonar insert samples from a virtual instrument. It seems to me like they need the full roundtrip delay to run a synth - that samples are sort of inserted where audio comes into daw and need an extra input buffer size to run without crackles. Or if midi is delayed one audio buffer or something - that could explain some issues running VST midi plugins in Sonar.
 
I ran the same thing in Reaper, and it work just fine at 128 samples playing DP.
 
So looked at delay this firewire interface reported - and if it was 90 out and 150 in, or similar. Very different in and out.
 
Skipped firewire, and now running internal RME HDSP 9632 card at 64 samples, no problem.
Ran Sonar 8.5, X3 and now 2015 - no problems.
 
Just something I noted at the time, don't know what to make of it.
It seemed that the different delays in and out were involved somehow on the firewire - combined with how Sonar insert synth samples.
 
Lesson learned - interface+drivers may make a big difference.
 

Sir Lesinterface+drivers may make a big difference

A huge one. It's not made easier by many drivers not accurately reporting latency either. Often they miss out things like additional "safety buffers", sometimes the reported latency is simply wrong.

The only way to check round-trip latency is to loop a cable between an interface input and output, then use an audio track to send a "ping" to the output and record it being returned to the input, then calculate how long it took.

Or use a tool such as http://www.oblique-audio.com/free/rtlutility which does the work for you and makes it very quick and easy to compare performance at different buffer sizes and sampling rates.

tlw

Sir Lesinterface+drivers may make a big difference

A huge one. It's not made easier by many drivers not accurately reporting latency either. Often they miss out things like additional "safety buffers", sometimes the reported latency is simply wrong.

The only way to check round-trip latency is to loop a cable between an interface input and output, then use an audio track to send a "ping" to the output and record it being returned to the input, then calculate how long it took.

Or use a tool such as http://www.oblique-audio.com/free/rtlutility which does the work for you and makes it very quick and easy to compare performance at different buffer sizes and sampling rates.

Thanks for reminding me to do this. I found I was 38 samples out (ouch!).
I would add that after you've done it you should also do this for peace of mind with your new offset (use a clean sine wave, or better still a sawtooth you can line up):
http://forum.cakewalk.com/FindPost/2745971
 
 
I did both and both results agreed with each other...
 

John

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.
 
 

I think this is the cause. 

If the ProChannel made a huge difference to latency wouldn't it show up across all systems? Why might it increase latency for one person/DAW and not another? I use the ProChannel a lot and as far as I can measure it's no more resource hungry than any other set of plugins. The contents of fx chains aside we're all using pretty much the same set of plugin modules....

JWink,
 
Something else to consider about your comparison....
 
Cubase 8 is the latest incarnation.
 
Sonar X3 is not. 
 
And since some users have reported noticeably snappier performance with Platinum (over X3), it's probably worthwhile for you to try Platinum for a month and see how it fares.
 
Also, I'd personally suggest upgrading to Windows 8 regardless.  You'll definitely see better performance in Sonar (no matter which version).
 
Just a thought.

At the same ASIO hardware audio buffer settings you should get identical latency settings in all DAW's. 
If you are seeing a latency difference between SONAR and other DAW's you most likely have delay compensated plugins in your signal path somehow. Check your plugins and routing in SONAR. The easiest way to compare is to insert the synth in an empty project and test there with no plugins or PC modules engaged. Make sure you have no other apps using your audio device and that the audio buffer settings and routing to the audio interface is identical.
 
You may see differences in CPU performance but you should not see a difference in actual latency since SONAR doesn't add extra buffers to the audio processing stream.

I haven't seen any values posted - might be a good idea for the Features and Requests forum.  There are some other Cakewalk-included effects that can spike latency if used during recording, rather than for mixing/master.
 
I don't know the complete list of those - have seen some posted from time to time - I believe Concrete Limiter (listed above), as well as maybe Perfect Space, and Boost 11.  Pretty much anything that uses look-ahead processing could do it, from what I understand, and possible some that just chew up a bunch of CPU.
 
Hopefully some others with more direct awareness will post here with better information, 
 
Bob Bone