"Audio Dropout" toast occuring frequently at random times

[Colin Nicholls]

I wish there was more information available about the reasons behind the "Audio Dropout: The audio engine has been stopped unexpectedly".

This is happening to me when I am working with clips in expanded take lanes - just moving them around. Playback is NOT active at this time - there is actually no reason for the audio engine to be running at all, but by default, it is. I grab some clips and move them, holding down SHIFT to ensure they don't change their timing, release the mouse, and BAM, dropout toast.

It doesn't happen every time - and I have seen it happen when zooming in on the time line, also.

Additional Info: It often happens when I'm not making any actions in Cakewalk at all. It doesn't seem to be tied to actual activity in the UI.

LatencyMon isn't reporting any issues; typically 140 ms, peaked at 255 ms. All green.

Edited September 4, 2019 by Colin Nicholls

[David Baay]

Just to be clear, LatencyMon numbers will be microseconds (us), not milliseconds. In any case, 255 peak is not great, but shouldn't be a problem except, possibly, if your  ASIO buffer is extremely low, like 16-32 samples (333-667 microseconds at 48kHz).

I have very occasionally seen a dropout occur with the transport not running. It may be related to having Always Stream Audio Through FX enabled in  preferences.

One thing you can do is keybind the audio engine on/off, and toggle it off when doing big edits (or a bunch of small ones) that don't involve a lot of listening . I sometimes do it when dragging a big pile of MIDI notes to avoid graphical response delays because Cakewalk is prioritizing audio streaming. I also toggle it off when walking away from the DAW for an extended period just so it won't be wasting CPU cycles with a project idling since I have all the usual power-saving features turned off.

 

 

[Colin Nicholls]

39 minutes ago, David Baay said:

Just to be clear, LatencyMon numbers will be microseconds (us), not milliseconds. In any case, 255 peak is not great, but shouldn't be a problem except, possibly, if your  ASIO buffer is extremely low, like 16-32 samples (333-667 microseconds at 48kHz).

I have very occasionally seen a dropout occur with the transport not running. It may be related to having Always Stream Audio Through FX enabled in  preferences.

One thing you can do is keybind the audio engine on/off, and toggle it off when doing big edits (or a bunch of small ones) that don't involve a lot of listening . I sometimes do it when dragging a big pile of MIDI notes to avoid graphical response delays because Cakewalk is prioritizing audio streaming. I also toggle it off when walking away from the DAW for an extended period just so it won't be wasting CPU cycles with a project idling since I have all the usual power-saving features turned off.

David,

You're right of course. μSec not mSec.

[x] Always stream audio is enabled. Good point, I haven't really paid much attention to that option.

I run ASIO buffer at 256 samples typically.

 

 

[Noel Borthwick]

I wouldnt worry too much about that toast. All it means is that the system was busy enough that the time to process a single audio buffer exceeded the threshold and caused the engine to stop.

The reason it drops out even when not playing is likely because you have synths in your projects or you have "always stream audio through FX" enabled. So its telling you that realtime playback has been stopped. I'm sure there is room for improvement, but it can happen with some more intensive edit operations. 

[Colin Nicholls]

Thanks for chiming in, Noel. I'm now content with my current level of understanding of the behavior I'm observing. Go back to working on the next version!

[Colin Nicholls]

Some more information based on recent experiences.

Following the advice in this thread, several days ago I turned off [  ] Always stream audio through FX and it has made no difference.

It's not tied to specific actions in the UI as far as I can tell. I don't even have to be doing anything in the UI, just sitting pondering my next move, and POP I'll get the toast. I haven't been timing it so I can't say that it happens every 4 min 17 sec intervals (?) but to be honest it does kind of feel like that. Perhaps I'll start a stopwatch next time.

It's not crippling because I've even had it happen right before my mouse clicks the PLAY button and of course Cakewalk just starts the audio engine immediately.

But I have to think there is something abnormal going on.

My evaluation is that this is definitely a change in behavior, at least in my experience. It started happening since I updated 2019.07 and/or updating to Windows 10 1903. I can't exactly say which of these two events was the trigger.

I went through the usual post-update optimizations (disabling on-board audio, other unimportant services, etc).

UPDATE:

Launched Cakewalk. Opened project. Started stopwatch. Continued working in Cakewalk.

First audio dropout: 1 min 39 sec

Restarted engine by clicking on icon in Control Module; restarted stopwatch, continued working in Cakewalk.

Second audio dropout: 4 min 17 sec

...I kid not. I'm not saying this is anything other than a coincidence, but a pretty freaky one. I'll collect more data.

Third audio dropout: 9:23

Fourth audio dropout: Just after I closed the project, I wasn't timing specifically at that point.

Edited September 2, 2019 by Colin Nicholls
added some time intervals between observed dropouts

[Tez]

Call me crazy but... Since 2019.07 I get a higher frequency of the sporadic "audio dropout" toast when editing events, in the PRV, not in the PRV and no audio or midi activity (the keyboard was switched off).

The last time it occurred though, was at the start and at the end of a "bounce to tracks", this messed up the start of the rendered audio... On initiating the bounce, up popped the toast and I canceled it without saving the partial, restarted the bounce and let it finish and the toast appeared as stated, start and end. I had to close CbB and after a restart the bounce was fine. I appreciated Noel's remarks but it does feel like something's amiss, a bad pointer, memory leak or something... I don't know if the latest w10 monthly update "August 30, 2019—KB4512941 (OS Build 18362.329)" did something?

[Colin Nicholls]

I'm with you, @Tez, we can be crazy together.

For what it's worth, I temporarily switched back to 2019.01 and the frequency of audio dropout toast was much less. Then I re-installed 2019.07 and I'm back to seeing it every few minutes. 

It doesn't really impact my work (yet). 

I do wish I could download the installer for 2019.05 and others, just to compare behavior.

[Tez]

I keep backups of the prior "Cakewalk Core" folders, you may or may not already know this but if not check out this post

My 2019.05 backup is a composite of the 2019.03 hotfix full install, and the 2019.05 update, I suppose there is or was a full installer...

[Colin Nicholls]

I kept backups also, but around about the time they switched to the compact upgrade patcher, I missed a few.

Nice idea to rename the Cakewalk Core folder, I may do that from now on.

[Tez]

Stoopid question ? How do you create the "at sign" black background member reference... I've not ever used that anywhere??

[Colin Nicholls]

I literally just typed "@t" and a drop-down appears, from which you can use the cursor keys to select a possible user name. Then I think press Enter to save it in the message text.

[Starship Krupa]

If you start typing the username after the "@" the forum software will start making suggestions, too.

[Colin Nicholls]

More information:

I reverted to 2019.05 for a while, and my experience suggests that the dropouts happened less frequently, but not completely eliminated. Not enough evidence to prove anything either way, and I'm not seriously considering that 2019.07 made things worse, although that appeared to be my observation.

Now, the big news: I'm back on 2019.07, and the frequency of dropout occurrence has been reduced considerably since I disabled a couple of Windows 10 Services:

• HD Audio Background Process (RealTek)
• RealTek HD Audio Manager (RealTek)

These two services were enabled at startup. I have now disabled them, and random dropouts are much less frequent. Almost to the point that I would assume that nothing adverse was going on.

My DAW - like most PCs - has onboard audio support on the motherboard. It shows up in Computer Management > Device Manager > Sound, video and game controllers as "Realtek Audio". Following the historical advice/suggestion from @Craig Anderton, I have had it disabled in Device Manager for a while now. (along with "NVIDIA High Definition Audio" and "NVIDIA Virtual Audio Device (Wave Extensible) (WDM)")

On reflection, it seems that these two services from RealTek probably weren't adding any value seeing as the actual on-board audio interface was disabled...

I disabled the two RealTek services and rebooted.

So far, everything is working in Cakewalk as it should (apart from one incidence of a random audio dropout whilst idle).

I'm not saying this is a fix for the issue, but just reporting my experience.
 

Edited September 4, 2019 by Colin Nicholls

[Tez]

Very interesting Mr @Colin Nicholls ... Unfortunately it's not a viable solution pour moi, and the idle dropout suggests something else is going on. I'm wondering, have  you tried a project with audio only, that is no synths or FXs? In the past the only time I'd get one of these recurrent sporadic dropouts with splat, as I recall,  was a project using "Rapture Pro".  I mention this because on loading a Rapture Pro project sometimes Splat and now CbB will instantly crash with an "Access Violation" C0000005, caused by Rapture Pro, which I imagine is some pointer holding a bad address, and on a restart the project loads fine, which suggest an issue with the synth plugin, also sporadic. The current project that's giving me the toasts grief also has an instance of Rapture Pro, so is it possible a wayward synth is the root cause? Just a thought... Oh and with all due respects to Mr @Noel Borthwick, as for "I wouldnt worry too much about that toast", when it does happen on several occasions the PRV shows a random selection of greyed out piano keys, which sometimes can only be reset by closing and restarting CbB...

Edited September 5, 2019 by Tez

[Colin Nicholls]

Interesting. You may be on to something, @Tez. I started Cakewalk and loaded a project with audio only. Not even any enabled FX.
I then looked at the audio engine icon in the transport module, and of course it was Grey/Off. Huh? I thought. Why? It's usually always on by default when I work in Cakewalk projects.

When I press PLAY, the engine icon turns Blue/On. When I STOP, it's Grey/Off.

Ah, I think, is this is how it is supposed to work, perhaps? The only reason the engine light is on all the time, for me and my projects, is because either the [x] Always stream audio through FX is enabled (as it used to be in my prefs) or I have numerous VSTFX and instruments and "live" MIDI tracks driving VSTis, and suchlike.

So I go into preferences and set [x] Always stream and press Apply. Then I press PLAY, and the audio engine goes Blue/On, as expected. When I press STOP, the engine light remains Blue/On. Aha! I think.

Then almost immediately after I STOP,  I get an "Audio Dropout" toast and the engine is OFF.

Normally when this happens, i click on the engine icon to re-enable it. However, this time, in this project, with these settings, I can't. I have to press PLAY to get the engine light On again. Then I press STOP... and the light stays on.... and I wait... idle, with no action....  ok, looks like it's stable for now.

So, I've learned some things about how the audio engine turns on and off as you do stuff in Cakewalk. Thanks for the pointers.

 

The bottom line, here, is that since I started noticing this "idle dropout" behavior a couple of weeks ago, the engine has never not started when I explicitly needed it too; and I've never had a dropout in the middle of playback or recording. In that sense, this configuration is STABLE and I'm a happy camper.

Update: Oh, the idle dropout happened while I was finishing up and posting this reply. Go Figure!

Edited September 5, 2019 by Colin Nicholls

[Noel Borthwick]

You are using asio or wasapi? What latency are you running at by default?

If you are getting dropouts that frequently when running at moderate latency something is interrupting your audio driver. Cakewalk has a fuse to detect if audio processing was unable to complete within the allocated timeslot and pops that message. Unless you have a synth or plugin in the streaming path that is costly normally your shouldn't see dropouts esp when playback is not happening.

Does this also happen when playing your project or only when idle?

[Colin Nicholls]

Hi Noel, thanks for the questions.

Quote

You are using asio or wasapi? What latency are you running at by default?

Driver Mode is ASIO (Echo Layla 3G PCI). 
I typically run at 256 samples, 44kHz, 5.8 msec,  which gives me 12.6 msec round-trip.

Quote

Does this also happen when playing your project or only when idle?

The audio dropouts under investigation only happen when idle. When playing back or recording, I don't have dropouts.

( OK, to be clear, I have experienced a very occasional audio dropout when recording or playing back but I put those in a different class altogether; very rare, mostly due to my experimenting or loading up a complex project and trying something stupid. )

I've used these settings at least since setting up this specific DAW ( i7-8700 @ 3.2GHz), and I didn't used to see this "idle dropout" at all until recently. I think it started happening around Win 10 1903 and/or Cakewalk 2019.05 or .07.

My investigations have included:

• rolling back to Cakewalk 2019.01 and 2019.05;  (= no or minimal improvement);
• Un-checking the [  ] Always stream audio through FX preference (= no improvement);
• disabling Windows Services related to Realtek Audio  on-board audio interface (which I have disabled in Device Manager along with Intel(R) Display Audio), (= no improvement)
• Working in a project that contains only audio clips and no VSTi or VSTfx (=seems OK)
• Working with Bypass All Audio FX button enabled in Control Bar Mix module (=did experience idle dropout)

 

 

Edited September 7, 2019 by Colin Nicholls

[David Baay]

The Audio metronome is enough to keep the audio engine active all the time even in a new project with no tracks or synths loaded.

I'm wondering if some power-saving/CPU throttling feature that was disabled might have become re-enabled by the 1903 update or some other change in the system. I would double-check that things like Speedstep and C States are disabled in BIOS, Core Parking is disabled. and the power profile is set to High Performance. 

 

 

[Noel Borthwick]

Nothing has changed of any significance in 07 that would impact this area. Though Echo made great products, you are running a discontinued 15 year old device that doesn't have officially supported Windows 10 drivers. It's not surprising that it might behave sub-optimally in Windows 10.
I suspect something environmental in your system is affecting driver performance leading to the dropout rather than CbB. In ASIO mode all audio is driven by the  ASIO driver's thread rather than managed by Cakewalk. If the ASIO thread is starved for some reason it will cause a dropout. Most modern ASIO drivers take extreme precautions to guarantee real time performance of the driver, setting their thread priorities to realtime and other kernel tricks. 

Regarding why your dropouts seem more likely to happen when idle, its hard to say since there are many variables.  PCI devices especially legacy ones, are prone to interference from other devices on the system and can require tuning. Some things you can try:

Do you have MMCSS enabled in preferences? If enabled Cakewalk will try and change the driver thread priority to the MMCSS pro audio priority.  Check whether toggling that flag makes any difference. 

Try playing with the DropoutMsec variable in Aud.ini. This allows adjusting the tolerance for the drop out.

Do you have share audio devices enabled? Try toggling that off to let CbB exclusively use the driver.