Noel Borthwick

If you are using a laptop definitely make sure windows is set to high performance mode and preferably use it plugged in to AC power. 4) If my laptop is using just battery only ( i.e. not plugged into mains via the adaptor ), would that be more likely to cause 'audio engine dropouts', even though the battery still has ( say ) 50% charge left? When running on battery Windows is very aggressive about conserving power to the detriment of realtime performance. Its not surprising that your system is prone to dropouts. If you must run on battery then you MUST ensure that Windows is set to never sleep and always run in high performance mode. Also run with MMCSS enabled in Cakewalk. Additionally you may turn off dropout detection in Cakewalk by setting MaskDropoutDetection to True. When that is set, the audio engine will not stop even if a dropout is detected. You may hear a momentary glitch bug it will keep running.

If using onboard audio make sure that you have set the audio driver mode in Cakewalk to WASAPI Shared here: This is the default for windows onboard audio devices and should work for all sample rates even those that the audio interface doesn't directly support because Windows does the sample rate conversion. In WASAPI shared mode the latency is locked at 10 msec but it should be good enough for most use cases.

The issue has nothing to do with the audio engine. Its very likely to be a plugin in your project leading to this. Not hardware or Cakewalk itself or even due to a corrupt project. There isn't anything necessarily that we can "fix" without being able to reproduce whatever problem you are seeing or getting a dump file that shows the issue. If the app itself is not hung and you are getting silent audio, the most common cause is that one of your plugins has internally "crashed" and is producing silence or random floating point data. If you can reproduce the issue, use a process of elimination to remove plugins one by one till the project starts working again.

What driver mode are you using in Cakewalk?

You should always use ASIO mode with pro audio interfaces. In ASIO mode you can only use one audio interface at a time but you can still freely switch between them in preferences.

Yes. buses cannot start processing until all upstream tracks or other buses routed to it have finished processing their effects. Only then can the bus mix its inputs and proceed to processing the bus fx chain. If you have complex dependencies of tracks and other buses sourcing the main bus then those count towards the "engine load" since they are additive. In other words no matter how many cores you have if the work is serial multiprocessing won't help you.

As far as multiprocessing goes buses are tracks are pretty identical so I don't see why you should see a difference if you are testing the same chain of plugins in a bus vs a track. However, you have to be careful to eliminate dependencies on other other tracks routed to the bus. The bus has the additional load of waiting for all its dependencies to be computed before it can mix its inputs. You can also try this test using aux tracks instead of buses and put your plugins there. Behind the scenes as far as mixing goes there is no difference between a track or a bus. They are all mix buses internally.

That implies that you have added a scan path that contains non vst dll's.

MMCSS is always on by default. What changed is that we no longer turn on the ASIO MMCSS flag, because some drivers misbehaved with it. Load balancing is off by default since again some plugins don't do well with it. 64bit mixing has a trade off since it takes some additional bandwidth, so its not enabled by default. Multiprocessing should always be enabled.

@Piper Can you send a crash dump with the plugin that was crashing? We can contact the plugin vendor with the issue since its a plugin bug.

@msmcleod or @jon sasor [cakewalk] may be able to point you to some notes. We have an updated mackie control surface dll that I assume you are using in Cakewalk.

Checked or unchecked? If checking the double precision box did that then it typically means that there is some floating point overflow going on in the signal chain. By switching to double precision there is more headroom so it sidesteppped the issue.

Please forward any recipes to @Jonathan Sasor and we can look into it for next release.

I appreciate that troubleshooting these kinds of issues is very frustrating and laborious. Its an insane number of permutations of things that can cause such problems so unfortunately thats the only way. If you come up with a recipe that we can reproduce we can try and isolate it further and communicate with the developer in more technical terms.

Its not your system. The crash is from the plugin. Only the developer can solve it since it crashes in their code.

The dump file you sent is NOT from the 2022.11 release. In fact its a crash from a 2022.09 build. Are you sure that you are running the latest version, or did you send the wrong dump file? Clearly the same crash occurred in 09.

Re 1. Please try setting BounceFlushTailsMaxDurationSec to 0 in preferences configuration file and see if that prevents the crash. Re 2. Try turning on Send All Notes off on Stop under VST settings

Delete all is new and has a confirmation prompt.

Perhaps post in this section as well. https://discuss.cakewalk.com/index.php?/forum/45-track-project-templates/

You can reset the device and reload the driver's in Cakewalk, by control clicking the reset audio and midi button on the toolbar next to the transport.

Maybe you had a mix of 32 bit and 64 bit plugins with different ID's. It works fine here.

In theory yes. It was likely not implemented for that gesture.

2022.11 Update 1 has been released. Thanks for your help everyone.

Is it reproducible and new to this build? Capture a hang dump file and send a link.

@El Diablo 2022.11 EA build 21 has improvements for app startup on a network when there is no internet. There should be no delay when starting the application now. Shutdown should also be quicker.