Kill your network to reduce latency

bitflipper


This came up in another thread, and I thought it might be of general interest. It's an easy technique even if you're not a propellerhead.

As we all know, networks and DAWs do not always play well together. A NIC is very often the culprit when diagnosing excessive DPC latency, for example. Wireless NICs are especially troublesome. Windows exacerbates the matter by assuming that nothing - not even streaming audio data - is more important than network traffic. If all that weren't bad enough, sometimes the network adapter shares an IRQ with the audio interface. Sometimes, the mere presence of a network connection can cause dropouts, limiting how many tracks and effects we can have. It can be so bad that even setting buffers up to very high values won't fix the problem.

This is why some folks go as far as to not even have a network interface in their audio workstations.

The problem with that solution is that sometimes it's darned handy to have your DAW on a network. An internet connection may be required to authorize a plugin, for example. Many audio software products are only available via download. And a LAN connection is very handy for backing up projects.

A nice alternative to having no network at all is to have a convenient way to turn the network off and on. Yes, you could do that via Device Manager, Control Panel or Windows profiles, but these are less than truly convenient.

But picture a desktop icon labeled "Disable Network" and a companion shortcut labeled "Enable Network". Click - network off. Click - network on. That's convenience.

While this does take just a little effort to set up, once in place it'll be ever so convenient to take the network on and off line. Here's how to do it.

Step #1: obtain a copy of devcon.exe
This is a free download from Microsoft. The download includes both 32- and 64-bit versions in a self-extracting zip file. Get them both here. Devcon is a command line tool that gives you the same functionality as Device Manager - but you can use it in batch files and desktop shortcuts.

(Warning: both 32- and 64-bit executables are named devcon.exe. Make sure you pick the right one for your O/S.)

Step #2: determine the device ID of your network adapter
Open Device Manager, scroll down to the network card, right-click and open Properties. The Details tab will show its ID.

These IDs are pretty long, but you can use CTL-C to copy a device ID to the Windows Clipboard so you don't have to type it all out. But it really isn't necessary to use the entire ID. The devcon tool we'll be using accepts wildcards, so you can just use a portion of the ID. For example, my network interface's ID is

PCI\VEN_14E4&DEV_1677&SUBSYS_01AD1028&REV_01\4&117729E2&0&00E0

but I can specify it as *VEN_14*, which is much easier to type.

Step #3: create a desktop shortcut
Right-click in a blank space on your desktop and select New -> Shortcut. In the textbox, enter the full path to the devcon executable followed by the word "disable" followed by your network ID.

For example, on my machine devcon lives in a directory named "tools", so my shortcut command is this:
c:\tools\devcon.exe disable *VEN_14*

Click "Next" and give the shortcut a sensible caption, such as "Disable the Network".

Step #4 repeat step 3 but with "enable" in the command line

Create a second shortcut (or ctl-drag the first one), and substitute "enable" for "disable". This will be what you click on to turn your network back on. So my shortcut's command line reads:

c:\tools\devcon.exe enable *VEN_14*

Lastly, you can optionally assign icons to your shortcuts. Here's what mine look like:




You can use this same technique to disable any device that's causing problems, such as DVD drives. And there are many ways to extend the concept, such as invoking a batch file that not only kills the network but also stops unnecessary background processes. Or starts SONAR at an elevated priority, or runs it as Administrator. Or writes the date and time to a file if you're billing by the hour.


Now, want to see if this really has a measurable effect on your computer? Start up DPC Latency Checker and note the values. Click on your new "stop network" shortcut while the DPC Latency Checker is still running. You'll see a big red spike as the network shuts down, but after that you should see reduced average latencies.

Of course, if your network adapter was never a problem in the first place, you can ignore this entire post.

Philip


SeveredVesper and RogerS,

Hopefully you'll be able to adjust these 'beginner' scripts to suit.  There are many google sites to learn from.  I've updated/tweeked the scripts a bit ... which I'll place on my other thread, here ... after others give there input.

I lust after programming solutions to make artsy inspiration a bit easier.  I program a bit for my day job (to survive).  I learn mostly by googling and lurking forums.

Most of you Sonarites do the same thing within Sonar's parameters and Sonar's 'higher' language.  Still, I'm pretty stupid (but dumb) with a lot of Sonar concepts, even after 3 years. 

I appreciate your expertise a lot, SeveredVesper.

henkejs


Not to take this thread too far off track, but I'm wondering if anybody else has had trouble identifying the device or service causing the DPC latency problem?  I'm getting a steep DPC latency spike on my WinXP system every 7 seconds like clockwork.  The rest of the time, the latency is very low.  I've gone through the device manager and disabled pretty much every nonessential device from the network adaptor to optical drives, and it didn't make any difference.  I've disabled several obvious services too, and I can't find the culprit. 

Does the regular timing of this spike suggest anything to anyone?  I'm not sure where to look next. 

Freeze 1st

Philip


NoKey, I feel like I'm exactly like you in this regard.

Henkejs: Freeze1st, gave me this Vista/Win7 optimizer info ... which I test drived today only and have had seemingly great results with it.  I'll share the info (at your risk): http://www.snapfiles.com/get/vsoptimizer.html

  I am going to try and take this ideal a step further. I've thought of this for some time but never was sure of a couple of things.

What I am going to do is create a .bat to have Windows changed to where it only loads up my daw and the resources it needs upon startup. I'm not sure if this is going to work or not but we shall see. BTW: I have everything securely backed up just incase.

What I'm going to try is first, I have a backup of the registry keys that execute the programs that start with Vista saved or backed up in a seperate folder, along with a FULL REGISTRY BACKUP.  What I hope to do is have the .bat file using command lines using reg.exe to do the following :

1st : Backup the registry as a second precaution
2nd : Change the registry entry to where the network is shutdown upon reboot
3rd : Remove the startup registry entries from the registry "In other words, no virus protection or nothing will load except windows", there want be a need for protection or any of those other programs that load with my system because I want be connected to a network and the only thing I will be running is my daw and windows.

4th : Import in the registry to where the only thing auto loading with windows startup will be my Daw.
5th : Have it Reboot the computer

If all goes well it will work, I haven't gotten into the driver registry entries yet, I'm just going to try this to see if it's possible.

Hopefully if this works right the .bat file will change everything back when I exit the daw and reboot, or I may have to write another .bat file to correct all this mess.

I used to do something similiar a long time ago with Windows 98, but there's a big difference there, because all I had to do then was have changes made to config.sys and autoexec.bat, mostly just copying and moving different configurations around. You can't do that with Vista it uses a parse setup.

Oh well, I DO NOT RECOMMEND DOING THIS TO ANYONE! But I thought I would mention this to you Philip and see what you think? It should be simple to do. Although the .bat file would change for each system because not everybody has the same programs that load up at startup automatically.

Bobby

bitflipper

If you're running XP, use a Microsoft tool called kernrate. For other O/Ss, use xperf. I don't have much experience with the latter, but have used kernrate to successfully identify which driver was responsible for DPC peaks.