Noel Borthwick

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.

No, I don't think so. Just watch for anything unusual with load times. Not waiting for the load just meant that the UI could flicker during project load since it would show the UI before all operations had completed.

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.

Not in build 17 I just made those changes today.

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.

31 minutes ago, GreenLight said:

I'm curious - where did you (the Bakers) get the inspiration/idea to work on improving project load times? Was someone having issues or did someone have an "Heureka!" moment? 😊

The improvements sound impressive, great job!

A few people had certain projects taking long to load with certain plugins, so we investigated it and found that some plugins can flood the message queue with data when loading.  Since Cakewalk was waiting for all activity to finish at load time, this caused the delay.

I've now also further improved load time on systems with no internet or poor internet speeds. The app should load immediately in such cases in the next build.

14 hours ago, tulamide said:

Ok, a weird issue. I was working on a song and at one point I replaced a synth with SynthMaster 2.9 (newest version). I opened its browser and selected specific patches, one after the other, while listening to a looped section of the song. At one point, I couldn't see any changes in the GUI of Synthmaster anymore (although the changes were made, i.e new patches selected), and part of its GUI was displayed on top of the Cakewalk GUI, far outside of the SM window. Not good. I closed the window, and with a bit of mouse movement and collapsing/expanding tracks, I was able to get rid of the SM garbage on the Cakewalk GUI. Opened SM again, and after a while, the same issue repeated. This time, after cleaning up, the window opened was just white (note, over the whole time, SM audio output was working just fine, reacting to the midi notes). I replaced SM with another synth, but the window again was white, and this time Cakewalk hung for 30 seconds and then crashed silently to desktop. I was able to retrieve a dump file from %appdata%\Cakewalk\Cakewalk Core\MiniDumps.

Dropbox link to dump file

 

I looked at the dump file. The crash isn't in any Cakewalk code and its impossible to decipher from the stack. There are a lot of Sitala threads there but it's not clear if it was responsible. Very possible that some corruption caused the crash. The problem with errant plugins is it can be very hard to track down from the DAW level if crashes are random because they can corrupt memory. Details from your dump are below. Something (not Cakewalk) is basically trying to read from a bad memory address somewhere. 

Based on your description the most likely explanation one of the plugins possibly ran out of memory and had poor error handling leading to this crash. The bottom line is there is nothing any DAW can do to protect from cases like this. If you have consistent problems with particular plugins your best option is to work with the plugin vendor to fix it. 

ExceptionAddress: 00007ffb092812a8 (ntdll!RtlDispatchException+0x0000000000000048)
   ExceptionCode: c0000005 (Access violation)
  ExceptionFlags: 00000000
NumberParameters: 2
   Parameter[0]: 0000000000000000
   Parameter[1]: 00000000000000bc
Attempt to read from address 00000000000000bc

PROCESS_NAME:  Cakewalk.exe

READ_ADDRESS:  00000000000000bc 

ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%p referenced memory at 0x%p. The memory could not be %s.

EXCEPTION_CODE_STR:  c0000005

EXCEPTION_PARAMETER1:  0000000000000000

EXCEPTION_PARAMETER2:  00000000000000bc

FAULTING_THREAD:  ffffffff

STACK_TEXT:  
00007ffb`092812a8 00007ffb`092812a8 ntdll!RtlDispatchException+0x48

STACK_COMMAND:  ** Pseudo Context ** Pseudo ** Value: 3 ** ; kb

SYMBOL_NAME:  ntdll!RtlDispatchException+48

MODULE_NAME: ntdll

IMAGE_NAME:  ntdll.dll

FAILURE_BUCKET_ID:  BAD_DUMP_MISSING_MEMORY_NULL_CLASS_PTR_READ_c0000005_ntdll.dll!RtlDispatchException

OS_VERSION:  10.0.19041.1

BUILDLAB_STR:  vb_release

OSPLATFORM_TYPE:  x64

OSNAME:  Windows 10

IMAGE_VERSION:  10.0.19041.2130

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.

On 11/26/2022 at 3:45 AM, tulamide said:

This version changed something regarding my personal issues. The first start, until the project selection window opens, is not faster. But the plugins do load faster at project load. They also open fast now (at least all of which I tested) in the DAW. But the "busy" moment after stopping the playback has not gone completely. It does happen when I run a loop and work a bit, especially MIDI. The display that normally shows the current time in the transport bar, and is used also to show progress when rendering or opening, shows a progress bar after 1 second, for maybe another second. I can only read about "saving", the rest goes away too quickly.

@tulamide try capturing a video while you stop the transport. That will show the exact message being displayed. Most likely this is autosave which if you have a big project will take a second to save the project. Perhaps one of your plugins is causing the project to get modified while playing.

Do you have auto save enabled? If so it's likely trying to save your project.

Try disabling that.

The slow start issue your reported should be solved in the early access build. 

Your other issue on stopping the transport was also solved in the 2022.11 release. By default Cakewalk doesn't send all notes off messages now which was the cause of the delay with some instruments and plugins.

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?

2 hours ago, Milton Sica said:

don't know what operations are carried out to close a Project, but I think that maybe it also deserves to be observed if there isn't something better in the routines, because I observe that for many seconds the application appears as NOT RESPONDING

Not responding is shown when the user interface is busy for a long time. Again this is most likely mainly due to plug-ins talking a long time on destruction. See if manually closing plug-in UI before closing the project makes a difference. Are you using 32 but plugins? This will also slow down further in this case because of bitbridge overhead.

3 hours ago, Milton Sica said:

What I can report is that projects that took 1.30 m/1.40 m to open now open in 30/35 s

That's good. Do you have an lot of open plug-in windows in your projects?

Most likely some plugins are doing excessive message activity when their UI is opened the first time, resulting in slowing down the project open. If you close the plug-in UI before saving the project is it still slow to open?

We initially were waiting for all UI activity to finish before showing the project to prevent flicker. Now we only wait for our drawing to complete. 

Is the load time better than prior releases as well or the same as it was in 2022.09 now?

1 hour ago, Milton Sica said:

Very good and working !

Are you seeing a change in speed loading your projects?

On 11/22/2022 at 8:47 AM, tulamide said:

Yes.
And the prior version is 2022.09
I also don't experience this issue with my other DAWs, for example Waveform and FL Studio.
As I wrote, I don't use any AV other than Windows Defender.
I will happily try the full installer.

@tulamide since you are the only one reporting this issue can you please try the latest build we posted.
There is a change that may resolve the issue you were seeing where some plugins could slow down project load times.

It's odd because there are no plugin related changes in 2022.11 compared to 2022.09. There are a few completely unrelated features that would not change this behavior and we don't observe this behavior.
Is this happening with all your projects or only a specific one. Please try and pare down your project to try and troubleshoot it further and find what tracks/plugins specifically are causing the slowdown. Then PM me a link to a zip file with the project that exhibits the problem and we can try and replicate it here if possible. Also if you have a second PC to try the same test it would be useful.

This article has some details on troubleshooting plugin related compatibility issues that might be useful.

Have you actually tried the rollback process to the prior version (2022.09) or are you speaking anecdotally based on what you observed after install.
Also its important to note which version you were running BEFORE you installed 2022.11. If you had a much older version that you aren’t comparing apples to apples. Most of the time slowdowns like this are caused by AV programs or other tools interfering with the process of loading dll’s by aggressively checking them.
Comparing other apps is meaningless because they are not loading 3rd party dll’s
Another thing to try is to run the FULL installer which is linked on the release notes post, then reboot your system make sure other apps are not running and try again.