Noel Borthwick

@OddSox The file was not available when I tried to get it. We look at dump files in Visual studio directly since we have the symbols. Windebug also works. However. without symbols you won't see very much .

@fossile the actual issue isnt related to pan law. When you bounce with source category clips, it's running each selected clip through the entire signal flow and captures the "as heard" sound. However, when it encounters a mono clip with channel format mono (or follow source), the clip gets upconverted to stereo at the end of the bounce signal path and then it gets converted back to mono when writing the file. this is where the 3db gain comes into play. I've fixed this by compensating for it for the next version.

There is really no reason to install asio4all for an audio device that has a manufacturer provided asio driver. At best it will perform worse than the native driver. At worst it will cause pain because it grabs ownership of the underlying wdm driver and will cause grief if you use the native driver.

If you can upload the crash dump or PM it to me we can take a look.

@Christopher Hunt Technically ASIO is a wrapper on top of the OS native driver model which is WDM. i.e an ASIO “driver” vendor must also ship a WDM driver for Windows itself to communicate with the device. There is no other way. So every device that has an ASIO driver needs to support Windows using the device at the SAME time as a DAW uses it via ASIO. Some devices do this well and others handle it poorly. For example Windows may be using the device at one sample rate while the DAW is using it at another. A well behaved driver handles all these scenarios transparently. All MMCSS does is set an elevated priority for the driver thread. This tells Windows to not interrupt the driver when doing other tasks which is useful when operating at low latencies. Cakewalk has supported MMCSS from day one when it was made available in Windows. At the time it was not part of the ASIO specification at all and almost no drivers supported it directly except a few like RME. So Cakewalk would set the drivers thread to MMCSS mode automatically to benefit from this (controlled by the MMCSS flag). This setting however was for both Cakewalk as well as the driver, until our recent release where we made it granular so it could be independently switched off for the driver. The reason for this was to avoid certain (buggy) drivers that caused problems when forced to MMCSS mode. The ASIO specification now states that ALL drivers should run in MMCSS mode but its still widely not respected. Pretty much the wild west out there Its not surprising because its an internal option that end users shouldn‘t need to worry about. In reality that isnt the case Most drivers don’t have a checkbox for this so its very hard to find out if the driver supports it without using tools like Process Monitor and even so its hard to find the driver thread most of the time. In Cakewalk I added a status if you hover over the performance module that shows the thread priority. If its 18 or higher its typically means that the driver is in MMCSS mode. However the technique I use to detect it isnt foolproof (Microsoft doesnt publish a way to check this!) Always choose ASIO inside the DAW. If you can use a different device for windows its preferable since it eliminates one common problem from the equation, since some drivers don’t play well when used simultaneously. I haven’t had issues with RME being used by Windows and Cakewalk simultaneously however. See my above notes. The technique I use isn’t perfect so if the driver has actually set it to MMCSS sometimes we just get a failure code when trying to set it to MMCSS but I can’t conclusively know if its actually running in MMCSS without running process monitor,

This has never worked with certain video formats. It didn’t work in SONAR as well. I’ve fixed it for the next release.

If your send a link to your project I can take as look at it.

Its pretty interesting that the issue occurs only on an AMD machine. I'll look into it some more but adding tracks have much interaction with the audio driver so that part is puzzling to me. Unfortunately, we don't have any AMD machines anymore to run tests on or I would have tried it.

Make sure you set cakewalk to run in WASAPI shared mode and select the headphone device as an output for your master bus.

@Light Grenade if you have a link PM it to me.

Moot. I've fenced it out of the next release of Cakewalk

Honestly it has no use especially in ASIO mode. Maybe we should just block it unless in MME or WASAPI shared.

Interesting. The wavetable synth from Microsoft internally outputs to the default audio output. So if Windows is using your Lynx its likely blocking the device. I've never seen this happen with other audio devices so you should report that to Lynx. I would expect the driver to share the audio device with both Windows and the ASIO driver client. But yeah disable the wavetable synth. It's a piece of junk that dates back to the 90's Here is an article on how to disable it in Windows. https://answers.microsoft.com/en-us/windows/forum/all/completely-disabling-ms-gs-wavetable-synth/5b2297a5-0904-4340-bdbb-ce528b3068c5 Maybe we should block it in Cakewalk itself by default...

Sorry that you are having such a nightmare with Windows. I have an RME UFX but it runs on one of my older computers with Windows 10 on it. I don't see any significant lags when adding tracks. I tested adding about 50 tracks and it still took about a second to add a new track after that. This is an older PC about 8 years old. I doubt that this is a Windows issue or RME issue directly. Have you tried resetting your audio configuration to defaults in preferences / Configuration file? Does the slowness even happen on a new empty project? One more thing to try. In preferences, disable all audio inputs and outputs except for the ones you are using. See if this makes a difference.

If you were using ASIO and output 1/2 was not working the problem definitely exists outside of Cakewalk. Something in Windows is possibly confusing the ASIO driver. I would ask Lynx support.