Colin Nicholls

Thanks for the suggestions, @Gswitz.

I'm going to keep posting my findings here. The driver re-install did not resolve the issue... I guess I just had a good day following the reinstall. I still think this stems from my install/update to Windows 1903. I realize this is perhaps just confirmation bias but I found these posts interesting: https://www.techpowerup.com/forums/threads/windows-10-1903-has-a-nasty-audio-stutter-bug-microsoft-hasnt-managed-to-fix.258611/ I realize that my Echo 3G drivers are almost archaic at this point, and this backs up Noel's point that older drivers can be affected by recent changes in Windows. I have actually downloaded an .ISO of 1809 and I'm prepared to re-install at a point in the future. (Unfortunately I can no longer roll back to my previous windows installation). In the meantime, the latest thing I have tried is this tweak mentioned in the post I've referenced: bcdedit /set disabledynamictick yes As usual, every time I change something on my DAW configuration, it seems to have a positive effect but I'll let you know if this is a permanent change 🙂

Ah, got it. Yeah, that's always off. I think I experimented with it once when it first appeared, and then left it disabled. I'm quite okay with Cakewalk owning the audio hardware while it's running. I will but... I don't want to jinx it, but... the idle audio dropouts have almost completely stopped happening since I re-installed the audio driver! Since our last correspondence, I un-checked the [ ] Use MMCSS option, and then decided that it wouldn't hurt to re-install the ECHO driver. Well... since then, I've only seen the idle audio dropout a couple of times, and in situations where I don't consider them unusual. If this was the only times I saw them, I'd never have considered writing a post about it. I've re-checked [X] Use MMCSS to see if that has a detrimental effect, but so far it still looks good. I hesitate to call this issue SOLVED (because I can still see idle dropouts, just not nearly as frequently) but if nothing changes over the next few sessions, I think I will do so.

John, I don't know the answer to your question, but if I create a new blank project; add a MIDI track, then open the PRV, I can scroll down and see all the way to C-2 which is the lowest note visible. I think this is related to my setting in Customization > Display, where I have Base Octave for Pitches set to -2.

I've updated the theme for September 2019; see top post for new zip and details.

Thanks for the insights, Noel. Yes, I do. I'll run some tests on that. In Windows configuration settings, Sound > Device Properties > Additional device properties > Advanced there are two check-boxes: Exclusive Mode: [X] Allow applications to take exclusive control of this device [X] Give exclusive mode applications priority I assume this is what you are referring to; let me know if there is a different setting. I hear what you're saying. I appreciate the support Cakewalk have given me over the years despite this fact. FWIW, this interface and driver have been rock-solid for me since Windows 10 rolled out in 2015. I've never wanted to be "that guy" that locks down his DAW to Windows 7 (although I've been tempted). One thought, though, I will try re-installing the driver, in case something has gotten out of whack.

Hi Noel, thanks for the questions. 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. 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)

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!

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.

Some of the changes can be subtle. In "Polar Blue" , Steve inverted the colors of the default track icons (to make them Black on White background), but in my evolution of the theme (Polar Blue 2019) I reverted some of them, reverting "sound source" tracks as white-on-black, but retaining black-on-white for "routing" tracks (i.e aux tracks, folders, and busses). I also fixed a pet peeve of mine and exchanged the "Synth" and "Instrument" track icons (because instrument tracks have both MIDI and audio so the icon should reflect that instead of the converse... but that's just me) So, yeah, at first blush it looks like nothing has changed but there are some subtle changes there.

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.

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.

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.

Ah... thank you scook. Clearly I paid no attention to that at the time 🙂 As you were, everyone...

Um... I just rolled back to 2019.01 to perform some tests, and my control bar modules are justified. Also, the right-click menu gives me the option of justifying them. This feature was added in 2019.07, right? So, why is it still available when I roll back to 2019.01? Are some components not replaced /reverted by the full installer? (Note: I would have gone back to 2019.05 if I could, but the most recent older full installer I have is for 2019.01.) I'm concerned because obviously now I am unsure if my tests really indicate 2019.01 behavior....