• SONAR
  • that DPC Latency Checker thingy...
2012/09/30 07:34:49
synkrotron
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
2012/09/30 07:42:25
Bristol_Jonesey
Sounds absolutely fine to me, hopefully someone with an in depth knowledge of it will chime in soon.
2012/09/30 07:50:35
synkrotron
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
2012/09/30 08:51:14
bobguitkillerleft
It seems since XP it super low[25us-not ms]is a thing of the past,my laptop hovers at 70-270us,my desktop always under 150,apparently anything up to around 1000"us" can be fine,depending on ?
Bob
2012/09/30 09:00:06
emwhy
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.


2012/09/30 09:54:19
synkrotron
Thanks for the input peeps. I'll have a look into Speedstep and HPET.

cheers

andy
2012/09/30 11:14:37
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.


2012/09/30 11:29:36
synkrotron
thanks for the maths there bitflipper, I need to get my head around that.

Your last sentence, about having Sonar open, do you mean I should take the measurements while no other programs are running, so that it is measuring the DPC latency of the behind the scenes windows drivers?
2012/09/30 11:31:30
Mystic38
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....
 

 
2012/09/30 11:44:50
synkrotron
Thanks for confirming that Mystic. 

I'll leave my lappy on for a few hours or so while doing nothing with it and see what the DPC latency checker comes up with.

If it is quite low with Windows Media Player running at the same time as X2 playing a big project then I'm pretty confident that I'm in the clear.
© 2026 APG vNext Commercial Version 5.1

Use My Existing Forum Account

Use My Social Media Account