Sounds like CPU shortage, but it’s not.

[jackson white]

Just got done with a bit of troubleshooting on a similar problem.  Running Win10 Pro with Updates disabled and still got nailed by a "security" update (I do those,)  The update changed the default sample rate for: 

Control Panel > Sounds | Playback | Speakers  

but NOT for Control Panel > Sounds | Recording | (my audio Interface) ... 

Took a bit longer to sort this out as I tend to keep an eye on Recording / Latency and assumed both would be the same. 

Getting them in sync solved the problem. It was pretty unusable until then. 

...

I'm OK with the challenges of maintaining an open architecture platform as it supports a much better bang for the buck, but having to keep on top of every detail can put a dent in productivity.  fwiw, my issues in order of probability have been;

MS/Win (mostly, with updates exhibiting an AI seemingly based on cockroaches) 

VST DRM and sometimes coding

User error (yep...) 

CxB  (it's what we're looking at when things go south but it's rarely been the problem)

Hardware (learned to stick with well proven components/interfaces/drivers...)

...

There's a solution in there somewhere. 

[Mark Bastable]

10 hours ago, bdickens said:

Yes.

 

Any time the computer is not receiving active input from you (ie typing or clicking with the mouse), it thinks it is sitting idle.

Gotcha.

In fact it wasn’t in ‘go to sleep when idle’ mode when  it was popping and wowing as I used CW.  It was in 'everything full on' mode, as you suggest.

 But later I specifically put it to sleep rather than turn it off, and that's when it made the 'something weird going on with sound' whine.

Edited May 30, 2021 by Mark Bastable

[Gswitz]

On 5/28/2021 at 2:50 PM, Mark Bastable said:

 

Thar she blows.

 

[bvideo]

Seems wdf01000.sys is a module that can be coupled with other driver modules for many different devices. The latency reporter combines the report for all devices that use that module. Finding which device is invoking that module with the outrageous processing times is a puzzle.

[Mark Bastable]

I haven't abandoned the thread. I'm trying a whole bunch of things, and I shall report back.

[Mark Bastable]

Right....

I've switched to WASAPI

I've done everything suggested in the vid that @Gswitz posted. Thank you.

I've done everything in a similar video from @Creative Sauce , which was, usefully, not all the same stuff.

I've also done everything suggested in another vid from @Creative Sauce about tweaking Win10 for music production.

At the suggestion of @jackson white, I've changed all the sampling rates I can find to 44100, though I don't know how I know whether I've changed all the sample rates that exist in various dark corners of Win10 or CW. Is there some kind of comprehensive list?

Chasing all this around the net, I came up with a possible problem associated with storage drivers on Lenovo laptops, that might have a detrimental effect on latency, I'm currently trying to work out whether that applies in my case, and what to do about it if it does.

And I also came across this, in the CW documentation, and I don't know whether it's relevant to my problem,
 

To enable/disable built-in DSP

In Windows 10, WASAPI Shared mode has support for configuring built-in signal processing for inputs and output independently. Many onboard audio devices have built in DSP, such as Dolby audio enhancement of audio outputs and noise reduction for audio inputs. While these effects may be desirable for better quality audio from laptops (for example, for noise gating of microphone inputs), the DSP processing of these effects can cause latency.

SONAR allows you to enable or disable DSP effects on inputs and output devices in WASAPI Shared mode. This is done via the EnableWasapiDSP variable in Aud.ini. By default, SONAR enables endpoint DSP effects for input devices (for noise removal).

To configure the built-in signal processing for inputs and outputs:

1.

Go to Edit > Preferences > Audio - Configuration File.

2.

Under Configuration Settings, click Edit Config File.

The Aud.ini file opens in the default Windows text editor.

3.

In Aud.ini, add a new entry called EnableWasapiDSP in the [Wave] section, and set its value to the minimum desired buffer sample value. For example:

[Wave]

EnableWasapiDSP=0

Valid values are as follows:

0 = Disable all signal processing for inputs and outputs (RAW mode)

1 = Enable signal processing for inputs (default)

2 = Enable signal processing for outputs

3 = Enable signal processing for inputs and outputs

4.Save Aud.ini and close the Windows text editor.

5.Click Reload Config Settings to reload the current audio configuration settings from Aud.ini.

 

Any thoughts?

I'm using WASAPI Shared now. If I try to use Exclusive I get a message that it's incompatible with some of my hardware. Does that tell us anything?

Also, the buffer-size slider is greyed out, as is the number-of-buffers dropdown. They weren't when I was using ASIO4ALL.  The buffer slider is bang to the far left.

The button which, if it were ASIO, would take me to a control panel now says "Wave Profiler" and it doesn't take me to a Control Panel, it just runs some tests.

And, in devices, I can only select one input and one output device. I'm pretty sure (I may be wrong) that using ASIO4ALL I could select multiple of each.

Lastly, completely independent of CW, I'm still getting a digital pop from the speakers when I turn the laptop on, though playback from, say, YouTube seems popless. On the other hand, system sounds do crackle. (Or did, when I had them turned on.)  But maybe this implies that the pop-and-crackle problem has nothing to do with the DAW at all.

My apologies if some of this info is banal. I don't know enough to know what's worth telling you and what's not.

Currently running Latency Mon for an hour with no CW running, and shall then try it with, to see if there's a difference.


 

 

Edited June 4, 2021 by Mark Bastable

[Gswitz]

Does latency monitor show green when you run it for 3 hours?

[Mark Bastable]

18 hours ago, Gswitz said:

Does latency monitor show green when you run it for 3 hours?

 Er, don't know. Shall I give it a go? Or are you very gently winding me up? Because I'm absolutely gullible enough to fall for it, believe me.

[msmcleod]

On 5/30/2021 at 7:39 AM, Mark Bastable said:

Gotcha.

In fact it wasn’t in ‘go to sleep when idle’ mode when  it was popping and wowing as I used CW.  It was in 'everything full on' mode, as you suggest.

 But later I specifically put it to sleep rather than turn it off, and that's when it made the 'something weird going on with sound' whine.

Putting your computer to sleep rather than turning it off is likely to cause problems. 

When awaking from sleep the state the audio driver thinks the audio interface is in, is quite often different from what it actually is - and this is what is causing the weird sound.  You're lucky it doesn't just crash.

This is completely down to the audio driver implementation, and nothing to do with Windows or CbB. 

The same applies for hibernate.
 

[Gswitz]

6 hours ago, Mark Bastable said:

 Er, don't know. Shall I give it a go? Or are you very gently winding me up? Because I'm absolutely gullible enough to fall for it, believe me.

No, I'm serious. You can install and run latency monitor. It is free and will point to your problem. Once you get it to stay green, you should be all set.

[Mark Bastable]

Ah, okay. Yes, I am using Latency Monitor diagnostically.

[Gswitz]

And latency monitor says your system is good for real time audio?

[Mark Bastable]

Intermittently.

I'll post the screenshots later.

[abacab]

On 6/5/2021 at 12:15 PM, Mark Bastable said:

Ah, okay. Yes, I am using Latency Monitor diagnostically.

Also, just mentioning here that "DPC latency" and "audio latency" are two completely different things. Make sure that you understand the distinction between the two issues, and that the solutions that you follow relate to the correct issue you are trying to remedy.

DPC Latency is strictly about the CPU and how well your PC is setup to handle Deferred Procedure Calls. Which can then cause your audio buffer to miss samples (crackles and pops) if the CPU is locked up with a long running DPC from another driver.

When a solution refers to something causing "latency", that is usually referring to "audio latency" (a delayed signal), which is the delay caused by the actual signal processing of audio in the PC, from the time an audio signal goes into the PC, gets processed, and then is sent back out of the audio interface.

Apologies if that distinction was already understood, but it's something that a newcomer to PC audio (anybody else reading this thread looking for answers) might not be familiar with.

[Mark Bastable]

19 hours ago, abacab said:

Also, just mentioning here that "DPC latency" and "audio latency" are two completely different things. Make sure that you understand the distinction between the two issues, and that the solutions that you follow relate to the correct issue you are trying to remedy.

DPC Latency is strictly about the CPU and how well your PC is setup to handle Deferred Procedure Calls. Which can then cause your audio buffer to miss samples (crackles and pops) if the CPU is locked up with a long running DPC from another driver.

When a solution refers to something causing "latency", that is usually referring to "audio latency" (a delayed signal), which is the delay caused by the actual signal processing of audio in the PC, from the time an audio signal goes into the PC, gets processed, and then is sent back out of the audio interface.

Apologies if that distinction was already understood, but it's something that a newcomer to PC audio (anybody else reading this thread looking for answers) might not be familiar with.

I totally understood the difference in the effects, but I wouldn't have got the terminology right, so thank you.

 

[Mark Bastable]

Okay,

 

Having done everything mentioned above, I was still getting pops and crackles, but less severely. Too often to want to work with though.

Following some trail or other, I found this...

https://www.tenforums.com/sound-audio/178473-solution-audio-glitches-how-ensure-general-real-time-performance.html#post2210762

Basically what it says is, Make the services that use the problematic drivers run on different CPU cores to the services that the DAW uses.

And it works. I have very few pops and crackles now, though some. 

It's not a full solution though, for two  - perhaps three - reasons.

1. All those manually assigned affinities and priorities  get re-set when you turn the computer off and on. So you have to do all this every time. It's a five minute job, but irritating. I'm currently looking at tools that claim to set this stuff up permanently.

2. You have to know which drivers are associated with which services and  - in the best case - thence to which processes. That's not always easy to figure if you're starting with what latency monitor tells you. WFD01000 crops up as a problem, but as @bvideosaid, it seems to couple with other drivers, and there's no way of telling which, so you have to hope that the companion driver that's making WFD01000 hit red is one of those that  you've coralled with the affinity assignment.

3.  I'm not sure about this, but I think that this solution makes latency monitor a less useful tool. Presumably if a driver is racking up high numbers, latency monitor's bars will go red, even if those high numbers are on CPU cores that the DAW's not using. Dunno. You can take a look at the Core tab to see what's working hard. but that's pretty difficult (for me) to interpret.

I'm stll getting crackles and pops, but not so often that it stops me working.  I'll carry on pursuing the issue and report back if I have any breakthroughs.

Edited June 9, 2021 by Mark Bastable

[abacab]

I have heard that some laptops might never be fully compatible for real-time audio, based on some online forum posts I've seen. Probably best to research up front before you buy one, in order to locate a model that others use with success.

Apologies for saying that, but it is possibly true. I build my own desktops, and the BIOS is usually wide open for tweaking with them. On the laptops I have owned, many BIOS items are locked down or hidden. That's probably just part of the problem, but some vendors have optimized their hardware for other priorities than real-time audio, as well as for reduced heat and power consumption.

A computer that is more than suitable for gaming or video editing may not be good for real-time audio, which is actually more demanding. Gaming and video editing are not actually real-time processes. They can buffer as much as needed to keep things flowing. See my next comment about that for audio...

Regarding real-time audio, I will mention that the fastest CPU on the planet is going to have issues if misbehaving drivers can tie it up so that it's unable to keep the audio buffer full. One strategy may be to set your audio buffers as high as possible, to see if that minimizes crackles and pops. This may not be acceptable for actual use, but as an exercise which may provide some insight.

[bvideo]

Disclaimers: I didn't watch any of the videos you did, and I don't know if your laptop has a LAN (ethernet) port. But if it does, and if you aren't using it, there are some designs for laptops that trade off hardware for software, which could cause the bad latency. In the software case, the software has to service a special part of the LAN at high priority in a loop. It's worst when the LAN port has no connection (no cable or nothing at the other end of the cable). Not even sure this would show up in wdf01000.sys, but if you haven't already, it's worth trying to disable the LAN interface if you have one.

[Starship Krupa]

One of the things that periodically bedeviled my Dell Latitude until I got a handle on it was something I'd never heard of called On Demand Clock Modulation. HWINFO is one of the utilities that can monitor it, and another program called ThrottleStop is what I used to eventually wrestle it to the ground.

I'd be cruising along just fine, running Cakewalk or whatever, and suddenly the system would bog down (Task Manager wasn't reporting a huge drop in clock speed, what ODCM does is start inserting idle cycles). I had to try a few different settings with ThrottleStop, but once I hit the right one, bye bye On Demand Clock Modulation.

It's unclear, On Demand Clock Modulation is something the BIOS can do to keep your laptop from getting too hot or using too much battery current. Mine was plugged in and not getting overheated (according to HWINFO), so I don't know what was triggering it to drop down to 25% of available performance. I don't care either. What's important is that I made it stop doing it.

This information about setting core affinities is new to me. It doesn't seem to make sense at first, I mean, why would restricting my audio process to a subset of my processor cores help with dropouts? The only way I can get my head around it is by assuming that cores 0 and 1 are likely to be busier than the other 2 or 6. It would be like daily air service from Seattle to Chicago: if you want faster service from the flight attendants, you should choose flights that are less likely to be busy. So if whatever it is that decides these things is more likely to put busy services like Wdf01000.sys on core 0 or 1, our audio services are more likely to get better service if we specify that they should run on 2 and 3 or 2-7. My question is: how do we know that the "busy" system services aren't going to be sent to core 2 or 3? Doesn't the thread scheduler assign them at random?

[Mark Bastable]

I thought it would be polite, and perhaps useful to future generations, if I just rounded off this thread.

First, there is a ton of evidence out there that apparently-random latency issues are common across DAWs, across PCs and laptops, across computer components - I mean, it's universal.

Second. as you might expect, there are many suggested issues that cause the problem, and they fall into a few categories.

1. It's resource-hugging drivers intermittently stealing resources from your DAW.

2. It's your device driver within the DAW. You've got the wrong one.

3. It's  your machine.  Probably your CPU or your RAM is deficient.

4. It's your Power Settings, or some other operating system set-up parameter.

5. It's a specific component of your machine - NVIDIA graphics card, for instance 

6. It's your WIFI, somehow. It's TCP/IP.  Something to do with that.

7. No, it's something else entirely.

And, as far as I can tell, none of the above is wrong. It could be any of those things.

In my case, rather frustratingly, it doesn't appear to be any single one of them. No - it appears to be most of them.

Each of the possible causes has several possible cures. Over the past couple of months, I've tried most of those that seemed relevant, to the extent that I understood them. I can't say I've really done this in any auditable, controlled way. I tried to, but there's too much of it and it's all too frustrating.

The latency has improved loads. It's not perfect. I mean, sometimes it's really clicky, and I think 'why now? what's your problem?' But generally it's workable with.

There's a gap in the market here for a comprehensive diagnostic tool. LatencyMon isn't really the full deal, though it's a damn sight better than nothing.