Tez

Once pointed to LatencyMon I started running it to identify ISR & DPC spikes and spikes = audio dropouts! “The definition of insanity is doing the same thing over and over again and expecting different results.” Well, that’s how it felt, I’d make changes to the system, do another run with similar if not identical results. Mostly graphics drivers, occasionally the HD Audio bus drivers and related kernel drivers would spike... But there were others though less frequently, and each time for the past couple of weeks, following a failure, I’d scan the drivers for viruses, google the web for potential solutions for these diver latencies. Power tweaks were all done, background apps were blocked in settings, USB, ethernet and power management options were changed, but every 20+ minutes or less a spike would occur depending on when I started a LatencyMon run. This is a ubiquitous issue for gamers, audiophiles and the like with a glut of solutions from tweaking the bios to re-installing or updating drivers and other tweaks. My drivers, bios and w10 are all up to date, and I concluded that LatencyMon shows what spiked but not why, and can send you off down a maze of rabbit holes, so I figured it might be specific to the machine OEM... I’ve got a Dell XPS 8900, and I noticed a “Dell SupportAssist Remediation” service running, and it turns out other Dell users had issues with this service. This service is supposed to scan the system on startup for hardware issues and auto generate a support ticket if any are found but only generates the ticket if you’re not out of warranty, and I am, hence a completely useless activity! What it’s doing beyond startup I dread to think! I disabled the service and ran LatencyMon for over an hour without spikes and similarly a CbB test project for over an hour without any dropouts... So, if you’re CbB on Dell user with a similar issue, maybe this tale of frustration and anxiety might help ☺️

Take a look at:

Well, on an optimistic note just before crashing I decided to run my test one more time, only this time I checked the "Always Open All Devices" option, the performance module showed CbB happily bouncing though each logical core, and it ran for more than half an hour with no dropouts. The interesting thing was that LatencyMon showed a spike on a graphics related driver, issued it's red audio issue warning right in the middle of the test, but as stated CbB was unaffected 😁... So I can sleep a tad better tonight. But... I'll have to run it for longer tomorrow and hopefully with the same result. On my prior PCs all had third party sound cards installed as a build option, but not this one, and I'm not good at playing with a pc's innards, and external devices had their drawbacks back then. Anyhoo tomorrow's another day...

Yup that's the ISR which I believe kicks off Wdf01000.sys - Kernel Mode Driver Framework Runtime, Microsoft and that's the spiking DPC. It turns out the latency issue with Wdf01000.sys is all over the web going way back and no solution that I can find, except to bypass windows drivers altogether and ASIO4ALL has been updated since 2017... So will keep looking for a solution...

What were your dropout codes? Well, one and all thanks again for all your input! I have to remark that with 4.01GHz core and 32GB ram my system should be amply audio capable, and by and large it is. The test performed (described above) does nothing but stream audio silence to the FXs. LatencyMon shows several drivers with spiked DPC execute times, and these cause underruns resulting in an Audio Engine dropout 1. Namely the Kernel Mode Driver Framework Runtime, I believe triggered by the High Definition Audio Bus Driver and also the Port Class (Class Driver for Port/Miniport Devices) used by audio devices, and in this case both I believe are audio related, and last the NVIDIA Windows Kernel Mode Driver, which is up to date as is W10. This test was also done with no internet, no router and the AV off, same result. These sporadic spikes are the problem, the performance tweaks are in effect, so the question is what is causing them. If anyone has had this particular issue and has fixed it please let me know...

So far, conducting multiple tests as described above: And using the settings described in the OP, the audio dropout 1 occurred after about 15 mins and LatencyMon showed a big spike in HDAudBus.sys driver. No event errors occurred during the tests, and the same result occurred for several test repetitions . Incidentally, running LatencyMon whilst writing this without CbB running, just the browser, the same spike occurred. The system is always up to date, so as to what this means I'm far from sure, is it the driver's poor performance or the task using it, CbB is using WASAPI, the browser isn't. Power throttling is disabled, no page faults occurred for CbB, and it seems this spike is the best candidate for the dropout, although other spikes possibly misleading, can show up. So I'm at a loss as to how to fix this. As to Realtek ASIO I share the opinion of Mr @scook ...

@Prod.Lostboy Anything that might help, so thanks. Just about to embark on my own LatMon odyssey... Wish me luck 😵!

Not as yet, just being cautious, but if as you say there's no down side, I'll see what relevant. The "power/USB management" did pique my interest as the midi input is via USB, but as I mentioned for the test above the midi was not active, and the dropout occurred regardless with no activity whatsoever. Other than the mouse as far as I'm aware, there's no other USB input I use for CbB. So I'm curious, in what way is it crucial, and am I missing something? Anyhow thanks for your help, much appreciated! Update: Just applied the power option tweaks, much of the others like "Privacy Options" were off or just don't apply to my system and for the moment deferring the optionals. I just realized that I can always revert to the previous "Preferred" plan if "High performance" has issues. So, will see if this improves dropout frequency first... Update: Just ran my test mentioned above, unfortunately despite the tweaks an Audio Engine dropout 1 occurred with no activity or midi input whatsoever. So, hopefully LatencyMon will reveal something...

@JonD I just ran a test with a project where my synth is Pianoteq with Ozone 9 in the FX rack, and REmatrix in the prochannel of a bus. The midi input for the synth was set to none, the echo was off and the midi keyboard was switched off. I walked away for a while to see if a dropout might occur with no activity or midi input. Without fail it did, an Audio Engine dropout 1. My question is, if you might know, how would I use latencymon to track down the cause, as it seems to me for this scenario something might well be affecting CbB. I'm assuming that the "LatencyMon.exe" is a standalone app not an installer?

Well, when I check the resource monitor all cores are active, if parked it should say so, no? I was under the impression that desktop w10 core parking was disabled... I'm not familiar with latencymon, something I'll have check out. For DAW tweaks I've got the pdf "Tweaking Windows 10 for Music Production" from Creative Source, some of it might be appropriate, but this is not a DAW dedicated machine, maybe one day I'll be able to afford one, meanwhile I have to exercise caution... Regardless, thanks guys for the input, if some process or another is the culprit, hopefully I can track it down, this might be the case as I've noticed dropouts on simply opening a minimalist project... 🙄

Even on projects with a single synth and only a couple of FX plug ins, Audio engine dropouts keep occurring. These are the basic settings: WASAPI Exclusive, Buffer Size: 40.5 msecs, Multiprocessing Engine checked>Plugin Load Balancing checked, DropoutMsec: 1000, Midi Playback: 1000 msec buffers (the max allowed). I still get too many Audio Engine dropouts: mostly 1, occasionally 9 and even a 3. Dropout 1 often happens when nothing is going on, no activity, no midi input. I started using WASAPI hopefully to eliminate this plague of dropouts. If someone has any suggestions to fix this I’d be grateful... My system should be well able to handle CbB performance, basic specs can be found here:

I think I've narrowed the issue a little . For a completely blank new project, no buses, no tracks, no vsts, the template generates all the buses present when initially saved. For my 5.1 speakers, using WASAPI exclusive, this was set to 3 hardware stereo outs, but the template in this case only shows the 1st hardware out, which maybe an old issue. For a new project template that has some of the buses included in the track template the existing buses will persist. Saving the template without the existing new project's buses and inserting it into new blank project as described in the OP, half the time there is no issue, the behavior is as expected, but sporadically it will shutdown cakewalk on project close. It seems there's a conflict with a new project's existing buses and the track template's version of the same, and probably something more. So, I think this is a bug...

@Base 57 I'm not surprised you couldn't duplicate 2 & 3, it probably depends on the track template in my case the synth was pianoteq, the FX Ozone 7 and the audio out generates 3 buses, an input bus, a verb bus which uses Rematrix in the ProChannel and mix bus for the input & verb which sends to the pre-master. I also have a template that just generates the 3 buses mentioned using a blank audio track in the track pane, and guess what... Scenarios 2 & 3 don't happen. So, I'm speculating that it's an issue with how the FX and synth instances are being handled in the specific context in the OP. Now using the blank audio track bus template and independently inserting Pionoteq and the FX , for each new untitled project, scenarios 2 & 3 don't happen. Whatever's going on must be complicated 🙃 ... Update: It seems the issue resides with the track template used in the OP, namely just creating a new blank project as before an inserting the track template in question, on closing the untitled project without saving also closes Cakewalk, this should not happen, typically the Start Screen should be invoked. So now I'm really confused 🙄...

I have a blank project template with an empty track pane and 2 buses, a pre-master with a send to the master which has all the sends to the hardware outs. Scenario 1. Create a new blank project, and immediately create a second new blank project. The window tab only shows the last blank project. An addition to the track pane of a project has to be made for a subsequent new project to appear in the window tab. Scenario 2. I have a vst3 synth track template, Midi source, Synth track folder and 1st audio out to a specific bus configuration and an audio FX in the rack. Create a new blank project, and insert the track template, create a second new blank project and insert the same track template. Close the first new project without saving and the Cakewalk app closes. Scenario3 Create new projects as per Scenario 2, and for each perform a “Save as” so now these are no longer untitled projects. Close the first project and the Cakewalk app closes. Last, since the projects were saved opening each one in the same cakewalk session, the behavior is as expected, namely closing one of them does not terminate Cakewalk and the other remains. This all seems a bit buggy to me...

Make sure you delete the synths and the associated tracks from the Synth Rack view, then try, "Save As..." from the File Menu, and choose a different name, then close the project and open the newly named project. If the problem persists it maybe you don't have full administrator privileges, then try launching Cakewalk as an administrator, and see if that's the issue, on saving your modified project. These are just suggestions of things to try, otherwise it doesn't sound like a CbB issue perse...

Silly question... Did you save the project before closing it?

@Base 57 Agreed, the Aux tracks need to be selected as they're just audio tracks with an aux input patch point, but the bus does not need to be selected. Since buses can be abandoned in favor of Aux tracks, it's tempting to think of them in the same way 🙄... This also applies to a generated Aux track as it's an audio, just as initially described for the audio track in my OP...

I concur, Project Templates under WASAPI so far hold their assignments as saved. With Track Templates, in addition to my OP, it should be noted that if the saved template has sends assigned to Aux Tracks, which are not present in the project these Aux tracks do not get generated, maybe this is to be expected as they are not buses, but if so why not? With regard to Aux tracks, if a project a track has a send assigned to to Aux track, and the given Aux track is renamed, this is not automatically reflected in the sending track, but the actual assignment still persists. Just another quirk, this doesn't happen for bus assignments, which always match the bus name.

Under WASAPI with multiple stereo hardware outs there are 4 selectable options from 1/2 to 7/8. The simplest scenario for odd track template behavior is to create an Audio track with the primary out assigned to 1/2, insert a send assigned to 3/4, and save the track as a track template. In a fresh project insert the track template previously saved and the “send” is not present as saved, just the primary out. Further, if the previous assignments were 3/4 for the primary and 1/2 for the send, not only is the send eliminated on the track template insert, the primary defaults back to 1/2. Similarly, if multiple sends to hardware outs were inserted, they would be eliminated. If there’s a “master bus” already in the project with just a primary assigned to 1/2, I observed the template track primary defaulting to the “master bus”. The above is just one case of track template functionality not as you would expect. In the case were a track template ought to generate buses and these buses send to hardware outs, there are additional problems which arise, with the generated buses. This probably should be checked out. If bus and aux track generation is not guaranteed for a track template when not already present in a project this should clarified.

Here is some very basic info for my system: OS Name Microsoft Windows 10 Pro Version 10.0.18363 Build 18363 Processor Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz, 4008 Mhz, 4 Core(s), 8 Logical Processor(s) BIOS Version/Date Dell Inc. 2.6.1, 5/23/2019 SMBIOS Version 2.8 Embedded Controller Version 255.255 BIOS Mode UEFI Installed Physical Memory (RAM) 32.0 GB Page File Space 4.75 GB System Disk: SSD, Data 1.86TB not SSD used for all CbB content & projects & most VSTs & VSTis... Video Card: Name NVIDIA GeForce GTX 960 PNP Device ID PCI\VEN_10DE&DEV_1401&SUBSYS_113810DE&REV_A1\4&89A4674&0&0008 Adapter Type GeForce GTX 960, NVIDIA compatible Adapter Description NVIDIA GeForce GTX 960 Adapter RAM (2,147,483,648) bytes Installed Drivers ...\nvldumdx.dll Driver Version 26.21.14.4112 So it should be OK for the stuff I do, just to keep me sane, and doubtless not quite up to your musical expertise, to say more modesty forbids 😌 I hope you'll get your studio up & running soon... I'm optimistic at this point that WASAPI will fix my glitches, so thanks for prodding me to use it! 😁

Well Mr @John Vere ... Unlike you I don’t do guitar & banjo live recordings, I’m midi oriented. As previously mentioned, Realtek asio sucks, the only other I have available is the FL Studio asio driver, which on my standalones offers 2 stereo outs (L&R) that work & I need 6, and never got it to work in CbB, so WASAPI would the only alternative to MME. I’ve got a chunk of old projects setup for 44.1 kHz, and a single Realtek stereo out redistributes to the 5.1 setup under MME as per my Dell audio settings. Under WASAPI I tried the shared mode, a test vst wouldn’t work without crackling, upped the sample rate to 48 kHz it seemed to work. Closed CbB without saving the project to reopen with the new audio settings no sound, reset the sample rate to 44.1 kHz still no sound, switched back to 48 no luck. Switched to exclusive mode which forced the rate to 44.1 kHz and it worked. Then switched the mode back to shared & it still worked. So, any new project has to be in exclusive mode at 44.1 kHz or vsts crackle or just don’t sound, and then temporarily switch to shared mode if required. So, way back when running into this mess without resolving it, maybe you can see why I stuck with MME. Any idea what’s going on? Anyhoo... Will set up the additional sends and see if WASAPI fixes these pesky audio dropouts, not mention the unprovoked render cancelations! Oh and I guess that selecting WASAPI exclusive mode forced the rate to 44.1 kHz, because the Dell audio config is set to that value, but for shared mode, and CbB uses it for exclusive regardless... 🙄

@John Vere Well, thanks for your comments, but just out of curiosity with your use of WASAPI for on board audio, what's your speaker configuration? Oh and what WASAPI mode?

@Jonathan Sasor Thanks for the response, but it's not predictable, it happens sporadically on different projects. The audio device is "Speakers/ Headphones(Realtek Audio)", horrible I know, using MME (32 bit), other diver options don't seem to work to well with realtek, and realtek asio sucks bilge water... The only commonality I can think of vst-wise is there tends to be an instance of Rapture pro in a project, and it maybe it happens that the unprovoked cancellation on a render will be the only issue. Rapture pro will crash a project very occasionally on an initial load with an access violation, so there may be outdated pointers hanging around. Also Audio Dropout (1), can happen when nothing is going on, except a simple gesture in the track pane... Don't know if the latter is due to constant streaming to FX vsts, if I've understood correctly , and in this case any advice would be welcome.

On a simple note sampling project with a synth stereo output and midi a track consisting of single notes, and a limiter in the stereo output track the following weirdness happens: 1. On first load of the project, a bounce to tracks for a single note immediately causes the Audio Dropout (0) toast, but regardless renders the bounce. Since this can happen repeatedly, I close and reopen the project and this then no longer happens. 2. On an extended bounce to tracks for a single track occasionally a Cancellation notification pops up asking if the partial render should be saved. Here the issue is that no cancellation was initiated manually! Incidentally this can also happen with other projects. As for the Audio Dropout (0), this can happen when nothing is going on, except a simple gesture in the track pane such as expanding a track or a folder! These sporadic Dropout (0)s are to say the least PITA... Any ideas, would be welcome...

Your welcome 😁... I read the doc & checked the dll which were in agreement, so I was just hoping what you said was true viz 2019.11, and regarding 2019.11, I just ran a project using 2019.11 and the current CW130Auto.dll. The project has automated volume and send levels for a number of stereo output tracks and as far as my ear could tell they functioned the same way as running the project using 2020.05. If this type of automation was affected after the 2019.09 change for prior versions, maybe the current CW130Auto.dll will suffice for all versions from 2019.09 going forward? Ya nevah know 😉