Update New Sonar Engine

[Jaime Ramírez]

Hi Bakers and people...

I am paying and trying the new Sonar Beta. I want to know if Sonar engine will be optimized for vst instruments performance. I am a cakewalk user since 1999. Since Gibson a buy it, 3 others daw, but my faith that the new Sonar performance will be upgraded is returning back and test again the software. Let us know... I am paying the bandlab subscription only for this reason, Having the others 3 daw updated. 

 

Thanks.

[Starship Krupa]

11 hours ago, Jaime Ramírez said:

I want to know if Sonar engine will be optimized for vst instruments performance.

Since you bought a BSP subscription just to test this, that's the best way to find out.

If you skipped past the past 6 years of Cakewalk by BandLab, the engine was given many optimizations during that time, so you should see a noticeable difference between SONAR and Sonar.

I've been using Cakewalk the whole time, and in my observations and testing, the engine is more stable and uses fewer resources than it did when Cakewalk by BandLab was first released.

It's more "it has already been" than "will be" optimized, but I'm sure that the developers will take whatever opportunities they can to improve it even more.

[Jaime Ramírez]

@Starship Krupa I work every week in the DAW. I never stop using. I install the last update that yesterday came out. I am a music producer (thats is my real job). I know. My only concern is the "crackles" when use vst instruments. In that scenario a don't see too much changes.(comparing with other Daws that is not happen). Since Gibson a live comparing and making tests. I think that the developers can work that part. 

[Starship Krupa]

4 hours ago, Jaime Ramírez said:

I never stop using

So you've been using Cakewalk by BandLab for the past 6 years and you have always had troubles when using virtual instruments?

And you're asking whether the developers have plans to improve the performance of Sonar in hosting virtual instruments.

I can only speak for myself, Cakewalk and Sonar seem to be not much different from other hosts for this use.

[Sergei Pilin]

For some reason the performance has been actually downgraded with Sonar taking significantly more CPU here compared to CW, in every project I've tried, from 10% up to 80% depending on the project.

[Starship Krupa]

On 4/27/2024 at 11:28 PM, Sergei Pilin said:

For some reason the performance has been actually downgraded with Sonar taking significantly more CPU here compared to CW, in every project I've tried, from 10% up to 80% depending on the project.

I haven't noticed this, but then again my system has 20 virtual cores, 32G of RAM and a 4GHz CPU to play with, so performance differences kinda get lost.

The current Sonar is supposedly still a preview and not a fully released product, so who knows.

As ever, if you've done anything to tune CbB like plug-in load balancing or thread scheduling model, make sure to apply those settings to Sonar.

[Sergei Pilin]

11 hours ago, Starship Krupa said:

I haven't noticed this, but then again my system has 20 virtual cores, 32G of RAM and a 4GHz CPU to play with, so performance differences kinda get lost.

The current Sonar is supposedly still a preview and not a fully released product, so who knows.

As ever, if you've done anything to tune CbB like plug-in load balancing or thread scheduling model, make sure to apply those settings to Sonar.

All settings are the same, but you're right, it maybe because there's lots of debugging code inside which will be later removed. My system is very similar to yours too, looks like.

[Starship Krupa]

On 5/1/2024 at 1:44 AM, Sergei Pilin said:

you're right, it maybe because there's lots of debugging code inside which will be later removed.

Indeed. Final optimization of things, etc. We'll just have to wait and see, but as I said, if anything, over the years the overall direction has been that the engine works more smoothly, requiring fewer resources. I hope it continues in that way.

[David Baay]

On 5/1/2024 at 2:44 AM, Sergei Pilin said:

it maybe because there's lots of debugging code inside which will be later removed.

Debug code is excluded at compile time for all public releases, including Early Access builds. So far as I know there are no signifiicant differences between CbB and Sonar audio engines at this point, and I cannot detect any performance difference in terms of late buffers  or reported Engine Load numbers. Meter and transport graphics animations have been optimized in Sonar so it 'feels' smoother, but there should be no audible difference.

[Ugo Fantozzi]

I'm upvoting this! Sonar needs a big big improvement in it's engine and should get real multi-core CPU support.

Right now I'm working on a project with lots VST synths (u-he Diva) and some Izotope plugins. 

The audio engine is dropping all the time with higher ASIO buffer sizes.

My meters (in Cakewalk) show a single core peeking 100% while all the 15 others are staying on about 10-20%.

This clearly shows Cakewalk is not optimized for multi-core CPUs.

[pwal³]

1 hour ago, Ugo Fantozzi said:

My meters (in Cakewalk) show a single core peeking 100% while all the 15 others are staying on about 10-20%.

what does task manager show?

[John Vere]

Izotope plug ins! Say no more. 

[David Baay]

8 hours ago, Ugo Fantozzi said:

This clearly shows Cakewalk is not optimized for multi-core CPUs.

More likely a particular plugin is heavily loading a single thread or some combination of plugins can't be effectively load-balanced due to their location in the project.

https://legacy.cakewalk.com/Documentation?product=SONAR&language=3&help=AudioPerformance.14.html

Cakewalk have been optimizing multi-threading and plug-in load-balancing as long as anyone in the business. If you can document a particular plugin or combination of plugins that disproportionately loads the first core in CbB/Sonar compared to some other DAW with an identically structured project. I'm sure the Bakers would want look into that.

[Starship Krupa]

On 5/29/2024 at 1:08 AM, Ugo Fantozzi said:

This clearly shows Cakewalk is not optimized for multi-core CPUs.

Compared to....?

[msmcleod]

On 5/29/2024 at 9:08 AM, Ugo Fantozzi said:

I'm upvoting this! Sonar needs a big big improvement in it's engine and should get real multi-core CPU support.

Right now I'm working on a project with lots VST synths (u-he Diva) and some Izotope plugins. 

The audio engine is dropping all the time with higher ASIO buffer sizes.

My meters (in Cakewalk) show a single core peeking 100% while all the 15 others are staying on about 10-20%.

This clearly shows Cakewalk is not optimized for multi-core CPUs.

You can't expect all of your cores to be balanced on every project.

Some processing need to be done in a specific order, and not all tasks can be split across threads, which means some cores will be busy, and others will be waiting on something finishing.

For example, you can't put reverb on a compressed vocal without doing the compression first, then sending it to the reverb - so the reverb part of the process will always be waiting on the compressor to finish. And if you've got another core that has a simple job to do on another track while that is going on, it's going to be sitting there waiting.

The larger the buffer size, the more data it has to work on - but is has a longer amount of time to do it.  The smaller the buffer size, the less amount of work it has to do, but has a much shorter time to do it.

If at any point the time it takes to do the work is greater than the time slot it's got to do it, you'll get drop-outs.

Sonar was the first DAW to implement plugin load balancing (most plugins at the time would only ever run on a single thread).  If you're using a lot of plugins that do their own load balancing, you might find better performance with plugin load balancing turned off  - if they're both trying to load balance, they may be fighting each other.   Plugin load balancing should definitely be disabled if you're using a small buffer size, as the overhead of managing the thread scheduling  may exceed any benefit of spreading the load.

The other thing to experiment with is the ThreadSchedulingModel.  You may see an improvement using a different model mode.