Sonar performance compared to Bandlab

[Sergei Pilin]

Hello,

A question to those who has directly compared performance of the new Sonar after the newest performance enhancements with Bandlab and has found Sonar is faster/snappier/etc. The reason I'm asking is under all circumstances with all different projects I've tried on two different computers with ASIO and WASAPI, Bandlab _always_ uses less CPU for the same projects and allows more plugins until it starts to crackle. I'm just wondering under what conditions these enhancements become visible.

[Colin Nicholls]

If you've performed your own comparisons between Sonar and CbB, on two different machines (with the same hardware config settings for each app of course), then you have the best data you could possibly get for your situation.

My experience differs: Sonar is equally as performant as CbB, if not "better". I use quotes because it is a subjective take. It requires a lot of effort to obtain hard data for definitive comparisons and honestly, I've never felt the need to put that effort in. I'm not even sure I'd be able to.

I'm not doubting your experience, but be prepared to have answers to questions like "how are you measuring CPU use" etc. 

[Sergei Pilin]

11 hours ago, Colin Nicholls said:

"how are you measuring CPU use" etc. 

I simply look at the Task manager with the same project running. Where Bandlab uses 30% Sonar uses 40%. Where Bandlab is one/two plug-in away from start crackling, Sonar is already crackling. So when I see in the changes "we made several performance improvements to the audio engine to improve CPU use" I wonder under what circumstances these improvements become apparent, maybe you need some Threadripper 24 threads CPU and the 10 threads one I have are not enough to see the improvement. Right now what I see is a perfomance downgrade compared to Bandland on _my particlual computers_.

[msmcleod]

29 minutes ago, Sergei Pilin said:

I simply look at the Task manager with the same project running. Where Bandlab uses 30% Sonar uses 40%. Where Bandlab is one/two plug-in away from start crackling, Sonar is already crackling. So when I see in the changes "we made several performance improvements to the audio engine to improve CPU use" I wonder under what circumstances these improvements become apparent, maybe you need some Threadripper 24 threads CPU and the 10 threads one I have are not enough to see the improvement. Right now what I see is a perfomance downgrade compared to Bandland on _my particlual computers_.

Do you have the spectrum analyser turned on in the console view?  Try turning it off - on some machines this can make a huge difference.

[Sergei Pilin]

19 minutes ago, msmcleod said:

Do you have the spectrum analyser turned on in the console view?  Try turning it off - on some machines this can make a huge difference.

I did have one channel visible with the spectrum analyzer, I turned it off and it didn't make much difference but it got me thinking - I tried to get rid of everything that was moving on screen - Piano roll, track view, everything that was animated on the Control bar, leaving just Console view so the only moving things were a couple of channel levels. It easily shaved off some ~20% of CPU usage (40 vs 33 in the Task Manager) which was much closer to Bandlab usage, so I guess most of the CPU usage difference comes from the new vector gfx overhead, mystery solved.

[msmcleod]

FWIW I've got an ancient 3rd gen i7,  4 core / 8 threads running at 3.4Ghz and 32GB RAM.  I'm only using the on-board intel integrated graphics.

I see massive improvements in Sonar over CbB especially with lower buffer sizes.

In saying that, I'm using a newer version of Sonar than is currently public - more engine optimisations have been done over the past month that aren't yet public, but even so, the current public release still performs better than CbB in most projects for me.

[pwallie]

are you guys (cakewalk) still using codejock for the gui, or is the new vector stuff moving away from that now?

[Noel Borthwick]

We stopped using that 20 years ago.

[Noel Borthwick]

3 hours ago, Sergei Pilin said:

I did have one channel visible with the spectrum analyzer, I turned it off and it didn't make much difference but it got me thinking - I tried to get rid of everything that was moving on screen - Piano roll, track view, everything that was animated on the Control bar, leaving just Console view so the only moving things were a couple of channel levels. It easily shaved off some ~20% of CPU usage (40 vs 33 in the Task Manager) which was much closer to Bandlab usage, so I guess most of the CPU usage difference comes from the new vector gfx overhead, mystery solved.

The low latency performance improvements are unrelated to GUI. If you aren’t seeing a difference its almost surely due to differences in setup between Cbb and Sonar. You don’t specify your CPU and OS configuration but even with 8 cores there are measurable gains.
Its important to note that any DAW level gains cannot magically eliminate CPU load caused by high load plugins.

The easiest way to measure the gains in Sonar more quantitatively is to create a benchmark project. Add something like 100 tracks with about 4 similar plugins on each track then test it at various latencies by archiving tracks until you get no glitching. You can also do the test with instrument tracks if you prefer. Also observe Sonar’s performance meters and watch for late buffers and engine load. In Sonar we see up to 3X gains now compared to old releases depending on the project workload.

Most beta testers and several users have already corroborated these results. The most obvious user visible one being that they can run their existing projects at much lower latency than before.

[Sergei Pilin]

4 hours ago, Noel Borthwick said:

The easiest way to measure the gains in Sonar more quantitatively is to create a benchmark project. Add something like 100 tracks with about 4 similar plugins on each track then test it at various latencies by archiving tracks until you get no glitching. You can also do the test with instrument tracks if you prefer. Also observe Sonar’s performance meters and watch for late buffers and engine load. In Sonar we see up to 3X gains now compared to old releases depending on the project workload.

I just did just that - Instance of a Spire synth playing 6 note chord with 6 voice unison. Added Fab filter EQ with some adjustments, Valhalla delay and Lexicon random hall. Then started duplicating this track until it started to crackle then removed one more track just to be safe - 54 tracks on some modest 6 years old 4 core laptop in Bandlab! Wow, that's some power we have nowadays! Opened this project in Sonar and it totally crapped out with cracks galore. Started removing tack by track, it sort of stopped crackling at 44 tracks but all sounded wrong as if the polyphony was reduced. Didn't want to find out what was up with the polyphony since it was obvious Bandlab TONS more efficient that Sonar anyway. Both programs have identical config settings and use WASAPI shared. I could try it with ASIO too but kind of lost interest since it's obvious for me that I don't want to trade that much of performance.

[Noel Borthwick]

Both programs have identical config settings and use WASAPI shared,

This is most likely the root cause of your problems. WASAPI shared has interactions with the Windows audio engine outside the control of Sonar. Also WASAPI shared isn’t performant at all with low latency. Esp with USB audio where it wont even go lower than 10 ms.

Please do your testing with ASIO (and when I say ASIO ensure you are using a native ASIO driver - not ASIO4All) and with no other application using the audio device. Which audio interface are you running? Low latency performance is very dependent on the quality of the drivers.

There is literally no way Sonar could be less efficient than Cbb engine since so much has changed under the hood.

[David Baay]

35 minutes ago, Sergei Pilin said:

Both programs have identical config settings

Compare your AUD.INI files side by side to be sure.

Do you still find Sonar does better with animations minimized? Try using the Pause button to invoke CPU Conservation Mode (limits UI updates to one per second).

[Sergei Pilin]

3 minutes ago, Noel Borthwick said:

Please do your testing with ASIO (and when I say ASIO ensure you are using a native ASIO driver - not ASIO4All) and with no other application using the audio device. Which audio interface are you running? Low latency performance is very dependent on the quality of the drivers.

Okay, will do and report. It's RME Babyface with my faster computer where I use ASIO and record stuff. The previous test was using the in-built laptop's Realtek sound, thus WASAPI

[Noel Borthwick]

Right, test using the native rme ASIO driver which is a solid driver designed for low latency.

Testing performance metrics with onboard audio devices is futile since there are factors outside our control that can cause glitching irrespective of whether the audio engine is efficient or not. I will do some testing in Wasapi at some point and see if anything can be improved but for now we're focusing on ASIO and plug-in performance.

 

 

[Starship Krupa]

4 hours ago, Noel Borthwick said:

I will do some testing in Wasapi at some point and see if anything can be improved

Those of us who take our laptops out to coffee houses and don't wish to lug around our Studio 2|4 or Scarlett 2i2 thank you in advance. 😍

That said, I see improvements on my 2017 Dell Latitude with a 2-core i7 using WASAPI Exclusive.

If any performance tuning has been done by a user within CbB, checking that AUD.INI is important. Thread Scheduling Model is key here.

Edited November 4 by Starship Krupa

[Sergei Pilin]

Just tested the same 54 Spire instances project with ASIO (96 samples) - Cakewalk wouldn't play it without crackles despite much faster computer, started removing track by track and the crackling stopped when I had 38 tracks. Amazing how low latency ASIO is so much more demanding than WASAPI. Sonar DOES play the original 54 copy project with no crackles! Although one more copy and it starts craclking too. So credits where credits are due - Sonar IS much more efficient than Cakewalk with low buffer ASIO.

 

P.S. Replicated this project in Reaper, stopped at 104 tracks which still were playing with no problems. Now that is some optimized engine

Edited November 4 by Sergei Pilin
more info

[Noel Borthwick]

Can you share the project you are using for your test please?

ASIO is not more demanding than WASAPI. Its the other way round.
Also in WASAPI shared that you were using, you cannot go lower than 10 ms, which is obviously going to use less cpu than 96 samples ASIO.

96 samples in ASIO is 2 msec latency.
10 ms at 48K is 960 samples.

In the upcoming build there are is a lot of further work that has been done to optimize the single flow so this same test should be a lot better.

[Sergei Pilin]

8 minutes ago, Noel Borthwick said:

Can you share the project you are using for your test please?

Here it is.

Spire instance test.zip

[Noel Borthwick]

Thanks, I just sent you a PM.

[Greg Wynn]

The more recent updates have absolutely optimized Sonar - I remember using it the first time after the update and the difference was immediately discernible.

And if there is even MORE optimizations then bring it on !  

 

 

 

 

Edited November 5 by Greg Wynn