Actually, pulling the cord worked fine since the auto detect couldn't work.

FYI - I commonly pull that on shutdown anyway because a computer can be remotely booted if hard wired (to get voltage to the card).

wondering if results of all these steps actually show in Sonar Preferences (Audio/Driver settings)..
or, if latency number is ok there I'm good I guess..not sure if that is your actual latency or just a calculation..
 

mettelus
Actually, pulling the cord worked fine since the auto detect couldn't work.

FYI - I commonly pull that on shutdown anyway because a computer can be remotely booted if hard wired (to get voltage to the card).

Disabling wakeuponlan in the bios or via the NIC's interface page will stop any machine waking up (normally disabled by default anyway). Even if it did wake up if the nic driver is disabled nothing would penetrate.

Your TCP/IP stack will still be running unless you disable the adapter. Anyway whatever works for you.

.

Wouter Schijns
wondering if results of all these steps actually show in Sonar Preferences (Audio/Driver settings)..
or, if latency number is ok there I'm good I guess..not sure if that is your actual latency or just a calculation..

Sonar reports what the ASIO driver tells it the latency is. This may or may not be the actual latency. Many interfaces have a built-in "safety buffer' that the driver does not report, some drivers have a "safety buffer" written into their code which might not be reported. The only sure way to measure audio latency is by looping a signal out through the interface and back in again and seeing how long it takes.

The latency that things like wireless network adaptors often cause has nothing directly to do with audio latency. It's a measure of "delayed procedure call" latency, which is how long hardware drivers are hogging the attention of Windows and the PC's PCI bus while they do their thing. Delayed procedure calls are what makes multi-tasking possible in a Windows/Intel system. For most of the things people use computers for - internet, office stuff, photograph editing, gaming - dpc isn't an issue because if an application has to wait 20 or 30 or so milliseconds the user will probably never even notice. DAWs and video editing software do notice because they need as close to a "real time" access to the hardware as possible.

Dpc latency can affect the minimum possible audio latency because if the audio driver's buffer runs out before the driver gets Window's attention back or can't be filled quickly enough then you get audio crackles and dropouts unless you increase rhe size of the buffer.

this is why i built a DAW with no connectivity.
 
nice.
 
 
but, as i prepare to upgrade my daw,
i'm needing a solution based around a wi fi connection (daw is where i cannot run cable)
 
once i do this, 
i'll need to get savvy about how to shut stuff off when i don't need it.
 
i can't imagine any reason to be connected,
except to upgrade software..
 
and i can do that now, without being connected,
albeit in a elbow around your @sshole kind of way.......

I got to test out the changes made above, specifically:
 
"Edit - Control Panel\All Control Panel Items\Network and Sharing Center\Advanced sharing settings - There are three options at the top of each section to turn on/off "network discovery," "file and printer sharing," and  "Public folder sharing." I had to set up a new network for this modem and just disabled these three. The "ndis.sys" driver is still #1 on the LatencyMon list, but significantly lower, and all of the "spiking" went away."

Although LatencyMon registers the network, there is no adverse affect to having the internet connected or even running. To stress test it I actually recorded real-time off YouTube and all was well. It seems "Automatic Network Discovery" is the ultimate problem child here, and is really an unnecessary function to leave active anyway.

Since I exhumed the thread, I wanted to be sure that was clear (for others 5 years from now :)).