Noel Borthwick

Fixed it. The MIDI export code was stopping the engine as a side effect of its processing but never resuming it when done.

Yes, I see the same. The interruption is normal while it bounces audio but then it resumes normally for me. I however did have one instance where it was not resuming so perhaps there is some corner case where this happens. Perhaps its dropping out.

Turn that option off.

Its vastly more stable with many hundreds of bug fixes and performance optimizations that CbB doesnt have.

Do you have Sonar set to share the audio device with other apps in preferences? If so when the focus changes from the app the audio engine is intentionally stopped. Dragging a clip to desktop is possibly changing the app focus. Turn off that setting and retest. Also - depending on what clip you are dragging from Sonar, the app may need to render the audio. If it does that it has to interrupt the audio engine (similar to export audio). However we should be restarting the engine after that - if not its an oversight.

Lots of deep infrastructure changes for next release so it's taking longer to complete. If all goes well it should be out next week

A lot of the performance gains come from optimizations for repeated operations that were consuming unnecessary CPU at low latency. Your system has only 4 physical cores so while you will see gains they won't necessarily be that dramatic as they are with lots of cores. The reason is that your system is gated by 8 concurrent processing threads out of which 4 are sharing cores. Your test use also artificial. So practically speaking, with 50 tracks and an equal workload, at best it will process the workload in 1/ 6 the time for each buffer. Whatever gain you see will be proportionate to this ratio as well. In the next update we've shaved off even more cpu cycles, so you will see yet more improvements. some testers reported up to 30 percent gains in their projects.

Please send a dump file as outlined in my post above.

Thanks, I just sent you a PM.

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.

If you are seeing crashes please submit a crash dump and we can take a look. Also please specify what audio interface and driver mode you are using.

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.

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.

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.

We stopped using that 20 years ago.