DPC Latency checker - how to interpret results

[Lourson]

I'm testing my daw with the DPC Latency checker (DPC Latency Checker)
and I'm not sure how to interpret the results, should I have all little green bars all the time, is one red bar every 3-4 minutes a bad thing etc...
Could anybody shed some light on this please.

FYI I'm getting one red bar, every 3-4 minutes, I have disabled every device suceptible of being the culprit, and I'm starting to wonder if one red bar every few minutes might just be normal

thnx

[Schaap]

Originally Posted by Lourson

FYI I'm getting one red bar, every 3-4 minutes, I have disabled every device suceptible of being the culprit, and I'm starting to wonder if one red bar every few minutes might just be normal

That's not normal! When you running DPC checker alone it should be at least beneath max. 60 us. What's the cause of the spike is, is difficult to say. If disabling any device( incl USB-devices) not helps it could be a systembackup thing or a device polling or etc......
In my systems the culpit were: bad graphic driver(ATI) and a 3com LAN ethernetcard.

You should look in the soundonsound forum (PC Music) there's a long thread about this with different mobo's, systems, solutions...


Henk

[initself]

Right now, my system is running at a latency of 4355 ms, constantly.

Yet, in Cubase VST, with a Digigram VXPocket V2 running ASIO4ALL at 64 samples, I am having a *wonderful* experience playing back multiple software synths.

As far as I can tell, I shouldn't even be able to use my system at all with that much latency, yet everything is stellar.

Can anyone interpret that for me?

Happily,

mb

thumbsup

[Nuno_F]

Originally Posted by Schaap

That's not normal! When you running DPC checker alone it should be at least beneath max. 60 us.

Henk

You can have perfectly good performance with much higher values. My current DAW is always around 100us and I have no glitches at all, regardless of buffer size.

[valis]

4355 ms (ASIO latency) or 4355 µs (DPC Latency checker results)? Is that *always* regardless of what is in the background or connected, or only when using Cubase with that card? etc...

As for having a wonderful time playing softsynths, I'm guessing you're saying that you are getting low latency performance without issues?

Lastly, watching deferred procedure calls is a way to gauge when something steals bus cycles in a way that you don't want, ie, monitoring for spikes. It's not the sole source of all answers though just another test.

[initself]

Turns out my victory was premature.

When I rebooted my system, I found that everything was haywire and the card couldn't playback anything below 256 samples. Horrible digital noise would result if I lowered the buffer size below this and the playback would change pitch as well.

I've had that happen a few times: some seeming miracle occurs and I can adjust the buffer to the lowest latency and seemingly do anything I want, but is the system really at that latency or was something just *stuck*?

So now I am back where I always am: the land of laptop audio frustration.

Sincerely,

[initself]

Originally Posted by valis

4355 ms (ASIO latency) or 4355 µs (DPC Latency checker results)?

4355 µs (DPC Latency checker results)

[LPK]

Normally you should always have only green bars, if no program is running. If you have often red bars, then there's something wrong.

Some audiocard-drivers however seem to be more resistant to such issues.
Anyways, it's better to sort the problems out and get back into the green area.

[stig109]

so is 3 to 8 with a max of 38µs good then?

[LPK]

That's very good.
I have an average latency of around 170µs with a maximum of 230µs at the moment (there are some apps running atm).

[valis]

An average latency of ~3000 certainly indicates something is wrong. The question would be, what? I watch the latency checker while using a cpu monitor and a few process monitor applications (like those from Windows SysInternals) and perhaps even Perfmon to correlate the 'spikes' I see with activity from a process/service/driver and/or cpu core which might be do-able with a constant high result but it's going to be harder imo unless something is just soaking up cpu cycles very visibly.

However unplugging unnecessary devices one by one (USB etc) and watching the results, then disabling unnecessary features in the BIOS and finally disabling things in device manager (and terminating any unnecessary processes) one by one should hopefully indicate where the problem is when something suddenly causes your DPC latency results to drop dramatically. This is the direction I would head at least...

[stig109]

Originally Posted by LPK

That's very good.
I have an average latency of around 170µs with a maximum of 230µs at the moment (there are some apps running atm).

Even with a few soft synths and cakewalk running it still doesn't get any higher than abou 75µs which I am really pleased with. Funny thing is I built the PC from a load of second hand bits I got from a friend who is really into gaming. I have enough parts left over to make a second one ( although slightly slower at 2.4gig core 2 duo ) and am wondering what to do with it.

[LPK]

I'd be interested to know which hardware exactly is in this PC.

@valis
Yes, sometimes it's hard to find. I had some serious problems on my PC and searched for days for the cause. I ended up reinstalling the whole system just to discover, the problem is still there.
After further investigations I found out, that the Windows7 energy-management was causing the problems.

[Timur Born]

Lourson, why do you use ASIO4ALL instead of the interface's original ASIO driver?

DPC Latencies should stay below 1000 us, good around 300 us, perfect around 100 us and anything below that is just a bonus that you wont recognize at even the lowest buffer settings.

The bigger your buffer the bigger the DPC latencies can be without causing dropouts. And you should be aware that it is only a hint for possible culprits, not an exact measurement.

You should measure them under CPU load (but not device load), using Prime95 while measuring usually works good. And you should *not* run audio (best even to deactivate/disconnect your audio interface) while measuring DPCs.

One big spike every few minutes can be problematic with small audio buffer sizes, because the audio buffers have to be transfered in *regular* intervals. If any other driver occupies the CPU while the audio driver needs to transfer the next buffer you get a dropout.

The smaller die DPC Latency (in reality it's not latency, but other drivers occupying the CPU) the higher the chance for the audio driver to transfer its next buffer in time (not conflicting with another driver call at the very same time).

Process priorities also play some role, not because they affect DPCs directly (these are higher priority than any process), but because when a process with lower priority than the audio application get less CPU to do its own work then it's less likely to do a driver call (DPC) at all.

[stig109]

Originally Posted by LPK

I'd be interested to know which hardware exactly is in this PC.

did you mean me?

Intel Q9550 running at 3gig
Asus Rampage Formula MB
4 gig ram
NVidia graphics, can't remember model but 768 meg, disabled in Device manager and using windows VGA driver which works fine without loads of crap being installed.
XP home SP3 trimmed down a bit and slipstreamed for install
Terrasoniq TS22 audio card

Network disabled in Device Manager

[LPK]

Thx for the answer.

[Sugarnutz]

This my ancient ASUS A8V with AMD Athlon 64x2 3800 & only two gig of ram running Win 7 Ultimate 64 bit. DAW is PT M-Powered 8.03cs1 into a Profire 2626 at 64 buffer with limited issues (Velvet causes s a few pops & clicks @ 64, none @ 128. Even Kontakt 4 Player runs @ 64):

[Amon]

Hi everyone, I'm bringing this ol' thread back to life, as it seems rather pointless to start a new one with a similar topic.

I had some issues with a re-formatted PC (thanks to Pete Kaine for his input in the specific thread: saw your answer too late, sorry!): now I've sorted out the drop-outs, they were caused by the latest update of Flux's BitterSweet, but I still have quite high DPC latency and the results are puzzling me.

The PC is a PE55-UD3, i5 750, 4GB DDR3 Corsair XMS3, Radeon HD5450, RME FF400, LaCie FW TI card, Seagate and WD HDs. Dual Boot with XP SP3 x86 and Win7 Home Premium x64 (the 2 OS are independent and unaware of each other).

Now, in Win 7 I always get measurements within the 100-350 micro-seconds range, varying rapidly, with occasional 500-800 spikes, in XP the fluctuations are less severe and less prone to spikes, although the average is pretty close. I do not experience any drop-outs (once I load Cubase the system becomes more stable, measuring a 150 average with little fluctuations)...but considered that my old P4 2GB DDR build measures 8-30 with a 130 maximum and my CoreDuo laptop 2GB DDR2 is just 10 micro-seconds above that, I still think something is not 100% OK.

If anyone could shed some light, it would be greatly appreciated.

EDIT: Note that in Win7 I also removed every driver and app causing problems like the WD external drive manager, the built-in audio driver (which actually runs flawlessly together with ASIO and RME drivers), the ATI Catalyst Control Center and so on. I had to keep the ATI visualization driver as the Win VGA driver seemingly does not support 1920x1080 resolution

[troggg]

I have a hopefully easy DPC Latency questions: if I'm running at about 160 us, with all good remarks and no spikes, with the stock onboard sound card, can I expect that to go down further with a quality audio interface using an Asio drivier?

[Timur Born]

Guys, stop wasting your time with this. Anything below 300 us is good enough for even the smallest audio buffer settings and anything around 100 us is perfect. Yes, most XP installations can go down to 10 us, but most Vista/W7 installations are around 100+ us.

You could try to deactivate the HPET in BIOS which helped some people lower DPC to XP values, but who in his right mind wants to turn off the High Precision Event Timer when he does timing based jobs like... music!

If you are on a laptop you might have to turn off the "ACPI compliant battery control method" driver via Device-Manager, because it can create spikes up to 1000 us (=only 1 ms!) every 15 seconds.

Anything else is of no concern with readings as low as your and any drop-outs you may still be experiencing very very come from another source. Not to mention that you didn't report dropouts anyway, so why care?

PS: If you are really serious about this you can forget about DPC Latency Checker anyway, it's just a rather simple "indication" tool. Use XPerf or LatencyMon (which is only a convinient way of using XPerf). Don't ask, google!

[Amon]

Originally Posted by troggg

I have a hopefully easy DPC Latency questions: if I'm running at about 160 us, with all good remarks and no spikes, with the stock onboard sound card, can I expect that to go down further with a quality audio interface using an Asio drivier?

No technical evidence to show, but I measured the same DPC latency prior to install the RME driver - actually, the fresh install is absolutely identical to the system as it is now with all of the drivers, applications and stuff.

[Amon]

Originally Posted by Timur

Guys, stop wasting your time with this. Anything below 300 us is good enough for even the smallest audio buffer settings and anything around 100 us is perfect. Yes, most XP installations can go down to 10 us, but most Vista/W7 installations are around 100+ us.

You could try to deactivate the HPET in BIOS which helped some people lower DPC to XP values, but who in his right mind wants to turn off the High Precision Event Timer when he does timing based jobs like... music!

If you are on a laptop you might have to turn off the "ACPI compliant battery control method" driver via Device-Manager, because it can create spikes up to 1000 us (=only 1 ms!) every 15 seconds.

Anything else is of no concern with readings as low as your and any drop-outs you may still be experiencing very very come from another source. Not to mention that you didn't report dropouts anyway, so why care?

PS: If you are really serious about this you can forget about DPC Latency Checker anyway, it's just a rather simple "indication" tool. Use XPerf or LatencyMon (which is only a convinient way of using XPerf). Don't ask, google!

Thanks for chiming in and for your input. My only concern was to have a system which resulted less stable, I'm actually pretty content with my setup...and a <0,2 ms is not a problem at all.

I'll try out the tools you suggested.

[troggg]

Originally Posted by Amon

No technical evidence to show, but I measured the same DPC latency prior to install the RME driver - actually, the fresh install is absolutely identical to the system as it is now with all of the drivers, applications and stuff.

Thanks.

[valis]

What Timur means is that there isn't a 1:1 correlation with your DPC latency results and your "this is how low my ASIO buffer goes" results. Deferred Procedure calls that are excessively large just indicate there's a resource conflict (or crummy driver more typically) and is just 1 of many tools used to troubleshoot things. So please let's not perpetuate a myth that it's an essential statistic when tuning an audio machine.

For instance I get a significantly higher DPC latency figure on my 8 core Xeon than I do my tiny AMD triple core box. Yet the Xeon will trounce that machine when it comes to any audio related task that's not single threaded, including handling the lowest buffer settings on large projects significantly better. Another good example of how judging by only the DPC figures could easily omit more important info would be when one machine is significantly older & slower. I have 2 machines here, one gets 15us under Xp32 and the other gets 90-110us in Win7. Based on that info alone, what does it tell you? Nothing really, since my 2001 era Prestonia Xeon rig with Xp32 gets 15us compared to 90-110us on my 2008 Xeon. There is still a difference there since the older box is on the RTC clock and the newer one is using HPET under Win7, but guess which still gets lower buffer settings ?

[Animus]

Originally Posted by Timur

Guys, stop wasting your time with this. Anything below 300 us is good enough for even the smallest audio buffer settings and anything around 100 us is perfect. Yes, most XP installations can go down to 10 us, but most Vista/W7 installations are around 100+ us.

You could try to deactivate the HPET in BIOS which helped some people lower DPC to XP values, but who in his right mind wants to turn off the High Precision Event Timer when he does timing based jobs like... music!

If you are on a laptop you might have to turn off the "ACPI compliant battery control method" driver via Device-Manager, because it can create spikes up to 1000 us (=only 1 ms!) every 15 seconds.

Anything else is of no concern with readings as low as your and any drop-outs you may still be experiencing very very come from another source. Not to mention that you didn't report dropouts anyway, so why care?

PS: If you are really serious about this you can forget about DPC Latency Checker anyway, it's just a rather simple "indication" tool. Use XPerf or LatencyMon (which is only a convinient way of using XPerf). Don't ask, google!

Absolutely correct on HPET. Turning it off you can go lower in DPC values "on paper" but in practice you can actually get better performance with it on when using low latency buffer with your audio card.

[Amon]

Originally Posted by valis

What Timur means is that there isn't a 1:1 correlation with your DPC latency results and your "this is how low my ASIO buffer goes" results. Deferred Procedure calls that are excessively large just indicate there's a resource conflict (or crummy driver more typically) and is just 1 of many tools used to troubleshoot things. So please let's not perpetuate a myth that it's an essential statistic when tuning an audio machine.

For instance I get a significantly higher DPC latency figure on my 8 core Xeon than I do my tiny AMD triple core box. Yet the Xeon will trounce that machine when it comes to any audio related task that's not single threaded, including handling the lowest buffer settings on large projects significantly better. Another good example of how judging by only the DPC figures could easily omit more important info would be when one machine is significantly older & slower. I have 2 machines here, one gets 15us under Xp32 and the other gets 90-110us in Win7. Based on that info alone, what does it tell you? Nothing really, since my 2001 era Prestonia Xeon rig with Xp32 gets 15us compared to 90-110us on my 2008 Xeon. There is still a difference there since the older box is on the RTC clock and the newer one is using HPET under Win7, but guess which still gets lower buffer settings ?

So let me clear my point.
Of course I don't think the ASIO buffer is directly correlated to DPC results, nor do I mean to perpetuate a myth I was not aware of. I also don't strive to have the lowest result possible.
Yet, this system has been (is?) unstable and I was asking if someone could see in my results a known behaviour, possibly caused by a component, driver or some hardware combination.

The 150-200 micro-seconds latency is by no means disturbing, but the fluctuations up to 700-800 just make me think there's something strange going on. In fact, today drop-outs on single channels in Cubase reappeared in the XP install - the one with the better measured results

By the way, thanks for your opinion as well.

[Tom music]

Well my problem was the darn Nvidia driver!! I was having severe red bars and went to the standard VGA and it is around 20. But, what is driving me nuts is I don't like the way everything looks lol. I know I cannot have everything, but I still wish I could use a better graphics driver. I tried all the tweaks etc but never could fix the problem. I have a geforce 220 that might be the reason. My fireface400 is working perfect! Anyway, for anybody with a Nvidia card might want to take the step of dissabling the the Nvidia driver 1st as has been stated.. Thanks for the info. I would have never figured it out without the info given

[Animus]

Originally Posted by Tom music

Well my problem was the darn Nvidia driver!! I was having severe red bars and went to the standard VGA and it is around 20. But, what is driving me nuts is I don't like the way everything looks lol. I know I cannot have everything, but I still wish I could use a better graphics driver. I tried all the tweaks etc but never could fix the problem. I have a geforce 220 that might be the reason. My fireface400 is working perfect! Anyway, for anybody with a Nvidia card might want to take the step of dissabling the the Nvidia driver 1st as has been stated.. Thanks for the info. I would have never figured it out without the info given

Might be a faulty card. Nvidea drivers generally work fine. I just went through this. I was getting glitches and spikes and after doing a lot of troubleshooting finally narrowed it down to one of my Nvidea cards that had been slowly failing over the last few months.

[Timur Born]

Known problem.

Download "PowerMizer Manager" and set the NVidia driver to a fixed 3D mode (Low Power 3D is sufficient for 2D applications like DAWs). It allows to switch modes without reboot, too.

[Tom music]

Timur, I thought I tried that but maybe I didn't ) I have tried soooo much!! Thanks for the help. I will follow up in a few minutes