that DPC Latency Checker thingy...

After seeing many references to the DPC Latency Checker, my curiosity got the better of me and I've downloaded it.

I ran it and watched it for a bit. Very nice.

Most of the time, the vertical bars are below the green line and every now and then they creep up to and sometimes past that green line. As yet, they have not gone past the yellow line.

As part of my test I had Sonar X2 running with a reasonably sized project of over twenty soft synths and a load of console emulation and stuff.

As well as that I opened the SWA Complete Sonar X2 video and played that too.

Sonar was using my QUAD-CAPTURE sound card and Windows Media Player used my internal sound card.

I then went to walk the dog.

When I came back I went to my laptop and was delighted to find that X2 was still playing my test project on loop and the Complete X2 video was still playing.

The DPC Latency Checker had peaked at 853 micro seconds and I would say that it is averaging around 200 micro seconds.


So, the question is, is this okay? It is still within the green band so I'm thinking it might be...


cheers

andy

Cheers Jonesey.

It's just gone into the yellow, sightly, so the latency peaked at 1097 microseconds. The large info pane to the left is still saying my machine should be able to handle real time audio.

and so it should lol

Readings in or near the yellow are OK unless you have a really huge project, but ideally you want to stay in the green. If you want to try to get things down into the green you might want to try to disable some things like wireless adapters for network and mouse if you have one. Also, I see you have an Intel machine  if you can get into the BIOS try disabling Speedstep and HPET. That will bring things down as well. My machine would peg into the red when I switched from XP to 7 in '09, but turning off Speedstep fixed that. I was still getting readings in the 100-200 range, but disabling HPET got me down to about 15 which is about as good as I can get with this system.

the question is, is this okay?

It's OK if you're able to do what you want to do without hearing dropouts, regardless of what the tool shows you. As long as the DPC latency is significantly less than the time it takes to fill your audio buffers, it probably won't interfere with your computer's ability to maintain a continuous audio data stream.


Example: your ASIO buffer size is 64 samples. If you're working at 44.1KHz, it takes 1.45ms to fill a buffer (0.0227ms per sample, times 64). (At a sample rate of 96Khz, it takes only 0.666ms to fill a buffer which reduces latency but also gives your CPU less time between buffer cycles to do its thing). If your DPC latency is really bad, say 4ms (which can happen) there is no way the CPU can do what it needs to do to the data. Not when it's getting handed a fresh set of data every 1.45ms!

But if, say, your buffer size is 2048 samples (which is what I use when mixing), at 44.1KHz the CPU has a whopping 46.5ms between buffer cycles, giving it plenty of time to process the data. (My DPC latency is typically under 20us.)

Your worst reading with DPC Latency Checker was 833us, or 0.833ms. That means the CPU would lose that much time out of the 1.45ms (1,455us) it's been allotted to process data in. The CPU therefore only has 0.722ms to get it all done (not only processing your audio but also managing all background tasks and driver overhead). 

Whether or not that's enough time depends on how many tasks the CPU has to perform in 722us. On a lean, optimized DAW it's probably more than adequate. 

One other important note...running DPC Latency Checker while SONAR is open will not yield useful measurements, because you'll be seeing SONAR's own DPC overhead included in the results.

bitflipper

One other important note...running DPC Latency Checker while SONAR is open will not yield useful measurements, because you'll be seeing SONAR's own DPC overhead included in the results.

@synk...
this is the important part.. to get quality data its best to run the machine without stuff running... what you are really looking for is for DPC to highlight short duration long interval PC issues...these are usually the real concern... (that occasional wtf crakle and pop)  and bestest it will then give you the data as to what/which process is the root cause... wifi adapters are an example of a short duration load occurring at long intervals... so you should be able to identify that 1097uS event by process and see what the issue is....
 

 

Bit summed it up pretty well.
 
In short, if you're working at ultra low latency (running heavy loads), low/consistent DPC latency is critical.
The further your needs are from this extreme, the less important DPC latency becomes.
A well configured current generation desktop can yield DPC latency that averages 2-8 uSec with an occasional peak in the 20s.
That's what you want for the best possible low latency audio performance.

tlw


If you're looking to solve a high dpc latency issue, it's worth downloading LatencyMon from http://www.resplendence.com/main. It not only monitors the latency but also lets you identify which particular processes/drivers are causing the problem, especially if you get big red spikes even with any wireless network adaptors disabled in device manager.

It sometimes seems to miss spikes that the dpc latency checker spots, but even so it can save a great deal of time compared to identifying the culprit process(es) by trial and error.

ah.. i was assuming thats the one Synk was using..............but mebbe not (as i read it again), but yup its the better one.

For me 300 is the absolute maximum .....the rest is not considered as optimized for audio but workable ..

Lappy :

Sony VGN BX 197 : 4 us !!  XP
HP 8710w : 35 us  XP
HP 8540w : -75-180  Win 7
HP 8560w : 90-180...Win 7 

MBP 17 (not kept) : 130-170 us win7

Desktop : 120us ... Win 7

That sony i sued to call it my "swiss horlogery" !!

twaddle:
 
Try LatencyMon - see my post above.

Jim Roseberry


Bit summed it up pretty well.
 
In short, if you're working at ultra low latency (running heavy loads), low/consistent DPC latency is critical.
The further your needs are from this extreme, the less important DPC latency becomes.
A well configured current generation desktop can yield DPC latency that averages 2-8 uSec with an occasional peak in the 20s.
That's what you want for the best possible low latency audio performance.

Wow,I was under the [mistaken,now I see]impression that W7 x64 introduced,a whole bunch of things that made the super low latency that YOU speak of,as a thing of the past,also isn't it kind of a bad idea,to turn OFF,the High Precision Event Timer?[HPET],as I seem to remember someone saying it[HPET] can be important,for audio related tasks?


An average of 2-8 us!!!,with a peak "occasionally" in the "20's"!!!,incredible low DPC,that is,and pretty un attainable for normal humans. 
RK

twaddle


Glad I found this post but I'm still in the dark.
I'm getting appalling latency that's well over the 16000 line.
I wish the latency checker would tell me which devices were the worst (or main offenders) I've tried disabling lots of things but 
still no chance and I'm getting awful clicks and pops that are making sonar almost unusable right now.
Are there any better programs that DPC Latency Checker that give more info as to what is causing the problem?

Steve 

Hi Steve,this one pinpoints to which drivers,etc are the worst offenders,instead of just freaking one out,with red bars,and such.http://www.resplendence.com/latencymon 
Bob

Jim, wow, I'll have to do some digging then, to get that low anyway. Generally speaking, before I decided to use the DPC latency checker, my DAW has been fine and I've had over twenty different soft synths all running at the same time, which includes Absynth with some CPU hungry granular effects. I was only using the checker out of curiosity really.

Hi Sync,

FWIW, You won't get a laptop (especially not off-the-shelf) anywhere close to the 2-8 uSec average.  

bitflipper,


Question for you.  If my Mixing Latency section is grayed out (currently reporting 4.4ms @ 192 samples), it seems that my ASIO US-1800 64-bit driver is preventing any changes in this area.  Not much I can do or do you have any suggestions? I'm also very confused on why my Recording Latency Adjustment (samples) section is showing my Blackmagic Audio card when it isn't even selected under devices.  When I use the dropdown and pick my US-1800, it doesn't hold the setting.

bitflipper

the question is, is this okay?

It's OK if you're able to do what you want to do without hearing dropouts, regardless of what the tool shows you. As long as the DPC latency is significantly less than the time it takes to fill your audio buffers, it probably won't interfere with your computer's ability to maintain a continuous audio data stream.


Example: your ASIO buffer size is 64 samples. If you're working at 44.1KHz, it takes 1.45ms to fill a buffer (0.0227ms per sample, times 64). (At a sample rate of 96Khz, it takes only 0.666ms to fill a buffer which reduces latency but also gives your CPU less time between buffer cycles to do its thing). If your DPC latency is really bad, say 4ms (which can happen) there is no way the CPU can do what it needs to do to the data. Not when it's getting handed a fresh set of data every 1.45ms!

But if, say, your buffer size is 2048 samples (which is what I use when mixing), at 44.1KHz the CPU has a whopping 46.5ms between buffer cycles, giving it plenty of time to process the data. (My DPC latency is typically under 20us.)

Your worst reading with DPC Latency Checker was 833us, or 0.833ms. That means the CPU would lose that much time out of the 1.45ms (1,455us) it's been allotted to process data in. The CPU therefore only has 0.722ms to get it all done (not only processing your audio but also managing all background tasks and driver overhead). 

Whether or not that's enough time depends on how many tasks the CPU has to perform in 722us. On a lean, optimized DAW it's probably more than adequate. 

One other important note...running DPC Latency Checker while SONAR is open will not yield useful measurements, because you'll be seeing SONAR's own DPC overhead included in the results.

Hi, Harpman. I'm an old-timer, too, predating not just Windows but also PCs and Macs. Having watched the evolution of hardware, software and the industry all those years gives you a sense of perspective, doesn't it? Like me, you've seen way too many "innovations" that ultimately didn't deliver, eventually revealed to have been purely marketing inventions.

I don't know if Vista is the best analogy for W8, though. I'm thinking more Windows ME.

Regarding not being able to get below 192 samples...the Mixing Latency adjustments are always disabled when using ASIO, since those settings can only be changed via the ASIO control panel. It's entirely possible the driver either has a hard-coded limitation (every interface has a lower limit that they offer as an option, although 32 or 64 are more common minimum values) or has determined for some other reason that 192 samples is the lowest you can go. However, it should be noted that 192 samples is still pretty durn quick (~ 4.3ms) and should be acceptable for most recording tasks.

Gio,

I have a QUAD-CAPTURE which is the little brother of the OCTA-CAPTURE and I am currently running in ASIO mode with an Audio Buffer Size = 4. This gives me an input latency of 3.3 milliseconds (144 samples), and output latency of 6.6 milliseconds (290 samples) and a roundtrip of 9.8 milliseconds (434 samples).


I've run a lower latencies than this but I start getting dropouts. I'm finding that I'm able to live with 10 milliseconds 


cheers


andy