Noel Borthwick

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.

On 1/5/2023 at 8:15 AM, Mannymac said:

Thats what I thought initially . But the bottleneck is not my machine it's the engine load in Cakewalk. As I said I can run the same plugin chains with the exact same routing in other DAW's just fine. I can even run the same chains in Cakewalk if they are on tracks not Busses. The problem is the engine load on Busses in Cakewalk. As to why that is? No idea.

I found out quite a while ago that with modern CPU's the bottleneck is the CPU no longer. My session only uses 20% of my CPU but the engine load within Cakewalk is about 95-110% (past 100% is where the glitches come) at 512 Buffer. That is where Reaper outperforms Cakewalk by quite a margin in my particular case. Or in Cakewalk's own words:
"The Engine Load value is a percentage of the total time the engine took to process an audio buffer. If it takes 100% or more of the allotted time, the buffer is processed too late and it will result in audio glitches/distortion."

When I run my buss chain of about 6 plugins on two busses so 12 in total via Audio Gridder I have 65% engine load at 128 buffer. So it performs faster and more stable that way. I am a happy camper with that.

I am using an RME ADI-2 Pro FS R as my interface, latest BIOS, no other programmes running, WIFI swiched off, latest driver for everything and an SSD. Given their excellent ASIO drivers I can say with a degree of certainty that won't be the problem either.

And again, exact same plugins on stereo tracks run just fine. Whatever Cakewalk does on Busses compared to tracks seems to place a higher load on the engine. But that is beyond my paygrade.
Cakewalk is the best DAW I ever used so I'm just glad I was able to solve this. I am no programmer so I have no idea if that is even possible but maybe there are ways to improve the way the engine handles Buss plugins. It seems I'm not the only one struggling with this so maybe an area for exploration for the bakers?

But then again, I know bugger all about programming. As always, it might just be that certain plugins don't like being on a Cakewalk Buss at which point there is nothing they can do and it is a compatibility issue.

PS: If Noel or any of the bakers want my session to check I'll happily pass it along.

 

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.

On 12/12/2022 at 8:19 AM, Alex3 said:

Little Update: I checked 64 bit precission Engine box and it got rid of the distortion I was hearing. Maybe that was also part of the problem

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.

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.

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

You said it's a WASAPI wrapper.
If it is doing low latency AND sharing, then it's not using WASAPI shared they are using something other than WASAPI.
 

Well even if they are doing WASAPI they are likely using WASAPI Exclusive mode rather than WASAPI shared. WASAPI shared mode cannot go lower than 10 msec for any USB devices so there isn't anything they could do to enable that. It's at the OS level.

We don't flag the FL studio driver. You can check the current list of flagged drivers in %appdata%\Cakewalk\Cakewalk Core\drivercompat.json

MMCSS is just a mechanism to let all realtime threads run at a very high priority so that other tasks on the PC don't interfere with audio processing as far as possible.
Have you turned off MMCSS altogether in Cakewalk or just MMCSS for ASIO?
If your system has enough bandwidth MMCSS won't help that much.

I've had the RME UFX for a long time and have had no issues with their ASIO drivers. The only thing is the device doesn't work well in WASAPI mode and in ASIO it doesn't support changing latency from the host side - you have to do it via the driver panel. Relatively minor issues.

Oh I didnt know they added an MMCSS disable in the driver panel, that is good.  He had mentioned it, but it wasn't available at the time.

It's not that surprising that you get worse performance if you turn off ASIO MMCSS in both CbB AND Lynx while leaving MMCSS enabled in Cakewalk, since that means the audio engine is running at a much high priority than the ASIO driver.

The recommended settings are the following:

Use MMCSS   ON
Enable MMCSS for ASIO  ON
MMCSS in ASIO driver panel OFF
 

Use MMCSS   ON
Enable MMCSS for ASIO  OFF
MMCSS in ASIO driver panel ON

NOT recommended:
Use MMCSS   ON
Enable MMCSS for ASIO  OFF
MMCSS in ASIO driver panel OFF

13 minutes ago, HOOK said:

Noel...I switched to Lynx Aurora Thunderbolt because the Universal Apollo x6 was blue screening over and over.  I'm still having to turn off MMCSS in Cakewalk with this Lynx driver.

@HOOK Lynx originally had a problem with MMCSS  on a Lynx E44, where the driver would stop responding when Cakewalk enabled MMCSS.  We had a case open with them and it was solved on their end back in Dec 2019, after I sent them a lot of info on this. Are you running the latest driver from them and if so, what problem do you see when MMCSS is enabled in Cakewalk for ASIO?

In any case this is exactly why I added the ability to disable it from the host level and no longer default to MMCSS being enabled for ASIO drivers.

This is why we advise never installing or using these drivers. What they do is hook into Windows and utilize the audio device via low level WDM.
Since at startup time Cakewalk loads all drivers to check for availability, when we hit this driver, it causes symtoms like you saw even if you never intended to use it. Sometimes it will even change the sample rate of your audio interface as a result of being loaded.
The best solution is to remove these ASIO wrapper drivers from your system so Cakewalk never sees them.

One thing I've been wanting to do is to change how Cakewalk starts up to avoid loading all ASIO drivers once one has been selected by the user. This might help alleviate problems like this. Its a pretty big change so will have to wait for when I have time to tackle that.

I wrote an article with guidelines for diagnosing plugin compatibility.
Though to an end user it might not seem that way, the vast majority of problems are caused by plugin’s not being fully robust under a variety of operations. The most common problem areas are with following VST3 protocols, loading and saving state, thread safety, and proper separation of user interface operations from actual processing. Bugs in these areas can result in symptoms that vary from user interface problems, audio glitches, problems bouncing, crashes or hangs. 

We capture crash reports when possible and they sometimes lead to a resolution, but plugin issues are one of the most error prone areas in any DAW. You say you don’t see the same issues in your other DAW’s but that in itself doesnt mean anything beyond possibly the fact that the plugin vendor has not tested the same operations in Cakewalk. All DAW’s are vastly different in their internal architecture and a feature that works perfectly in one may or may not work in the other. We take plugin compatibility issues very seriously and if it indeed ends up being an issue in Cakewalk we fix it promptly. In fact even if it isn’t our issue we do what we can to work around it - much more than what some other DAW’s do.

That message means the plugin was previously flagged as failing. If you have changed things, then change the VST scan preferences to “rescan failed plugins” and try scanning again.

It's probably not windows itself. Same issues on Mac. I don't think the OS knows if there is no Internet without actually attempting a connection. I was hoping it would return a cached state immediately but apparently not.

It so turns out that there is no Windows API to reliably detect no internet when you are going through a network/router. The known API's report a valid connection even when the router actually has no internet! Likely because from the point of view of Windows it is "connected".
I actually tested the API's and they report internet connectivity even though its dead. Windows itself actually pings the microsoft servers to check for internet.
See this article.

https://blog.superuser.com/2011/05/16/windows-7-network-awareness/

So in a nutshell the only way we can prevent this lag while checking, is by doing the check asynchronously.  I'll look into this for a future version...

Please attach or PM the crash dump file for analysis.
You can also try turning off flushing of plugin buffers in Preferences Configuration file. Some plugins misbehave with that setting.

How long is the timeout? It's probably doing the check for updates and timing out. It's quite fast when there is really no Internet but perhaps when it's on a lan with no Internet it's less efficient. 

I've now changed the API to check for an internet connection so perhaps it will improve.

How do I test your use case - just have a lan connection with no Internet?

12 hours ago, winkpain said:

For what it's worth, information-wise, I use Melodyne quite a bit, stand-alone and ARA in CW.

Every project that I've used with Melodyne/ARA in CW has this \Melodyne\Transfers folder in the CW project folder file, and every one of them is empty.  The \Separations folder located in \My Documents\Celemony (or wherever determined from within Melodyne Preferences) is the folder with all the pertinent data in it, it would appear. And this folder can grow quite large.

Maybe you added it by accident to an FX bin at some time. Or perhaps Melodyne itself creates the folder even though it doesnt need it. People copy projects with Melodyne all the time. I doubt that the separations folder is necessary and is likely used for internal temporary data. You can prove it for yourself by moving a project to a different machine or by temporarily renaming the seperations folder and opening an existing project. I bet the separations will be regenerarated from the existing project data.