Go Back   Cockos Incorporated Forums > REAPER Forums > REAPER Compatibility

 
 
Thread Tools Display Modes
Prev Previous Post   Next Post Next
Old 01-14-2009, 12:42 PM   #1
the all new rob
Human being with feelings
 
the all new rob's Avatar
 
Join Date: Dec 2007
Location: east coast of Kansas
Posts: 681
Default Using dpclat and RATT to diagnose audio performance problems

This is intended to be a friendly guide to using these two fine (and free!) tools to diagnose (not fix) problems with clicking and popping audio.

dpclat is a tool for visualizing the latency of deferred procedure calls by kernel-mode device drivers. In doing so, it also makes a good assessment tool for your system's ability to handle streams of audio or video. It's extremely well described on the linked page, so please do read that page and familiarize yourself with the background.

To use dpclat, you just run the executable (there is no installation needed). You will get a window with an updating bar graph showing you the time taken for deferred procedure calls (DPC) to all the drivers in the system. What it does not show is which driver is responsible if you have a problem.

The tool will give you a sort of "go/no go" visualization. If you get all green bars, your system (hardware and installed drivers) is generally well-equipped for streaming. If you get red bars, the tool is alerting you to the presence of a problem, but that's about it--finding which driver is responsible will be done with another tool altogether.

RATTV3 is that other tool. As described on the linked page, "RATTV3 is designed to help developers of drivers and other kernel mode components audit the ISR and DPC execution time of their components."

However, we will use it a little differently. In cases where we have red bars showing in dpclat window, we'll use RATT to find out where to start looking for the problem driver(s). What we do once we ind them is out of scope for this tutorial--I'm just showing you how to use the tool.

RATT gets installed and then runs as a system tray icon. It will start every time you boot until uninstalled, so make sure you are paying attention and don't leave it running after you are done troubleshooting.

With RATT running, take whatever steps are needed to reproduce your audio issue. You'll want to make sure to leave RATT on for at least three minutes to ensure you get a human-readable log file built. RATT will build a log file in the directory %system32%\logfiles\rattv3 based on the info it collects about DPC times. (note: %system32% is an environment variable--it can point to a different physical path depending on how you chose to install Windows. Look for a folder system32 under the folder where windows is installed.)

You then will open up the above directory in explorer, and open a text file named <machine-name>.cswa-accumulator-report.txt. Wordpad works much better than notepad for reading this file.

Inside this file you'll find a section for each kernel mode driver (DRIVERNAME.SYS). Each section is a histogram (sort of) of DPC times. There are 1109 possible "buckets" a driver call can fall into. A bucket is a range of duration times. What we are looking for is when calls to a given driver take longer than a few hundred microseconds. when we find that, we have identified a driver that could be behaving better.

The easiest way to spot the misbehavior is to look at the first column. the buckets we don't want to see will be numbered above 100. Ignore anything with a bucket number under 50. Those are too fast to matter. Any driver with items in buckets numbered over 109 is doing DPCs that take longer than a millisecond (1000 microseconds), and may be contributing to our performance issues. Further troubleshooting will be needed to determine that.

So a "healthy" driver would have a histogram like this:
Code:
Cumulative Histogram for:      Ntfs.sys  (Ntfs.sys)
  #,                  Range, Label,       ISR Count,  DPC Count,  DPCTmr Count
 10,   10.00us to   19.99us, <20.00us,            0,          0,            63
 11,   20.00us to   29.99us, <30.00us,            0,          0,            11
                              TOTALS,             0,          0,            74
And a driver that deserves further scrutiny would appear like this:
Code:
Cumulative Histogram for:     atapi.sys  (atapi.sys)
  #,                  Range, Label,       ISR Count,  DPC Count,  DPCTmr Count
 11,   20.00us to   29.99us, <30.00us,            0,       2269,             0
 12,   30.00us to   39.99us, <40.00us,            0,       4576,             0
 13,   40.00us to   49.99us, <50.00us,            0,        446,             0
 14,   50.00us to   59.99us, <60.00us,            0,         70,             0
 15,   60.00us to   69.99us, <70.00us,            0,         82,             0
 16,   70.00us to   79.99us, <80.00us,            0,         49,             0
 17,   80.00us to   89.99us, <90.00us,            0,         24,             0
 18,   90.00us to   99.99us, <100.00us,           0,         41,             0
 19,  100.00us to  109.99us, <110.00us,           0,        136,             0
[more like this...]
302,    2.93ms to    2.94ms, <2.94ms,             1,          0,             0
342,    3.33ms to    3.34ms, <3.34ms,             1,          0,             0
351,    3.42ms to    3.43ms, <3.43ms,             1,          0,             0
415,    4.06ms to    4.07ms, <4.07ms,             1,          0,             0
                              TOTALS,          7841,       7841,             0
So, low bucket numbers: good, high bucket numbers: bad.

There are also three different times being analyzed by RATT: execution times of interrupt service routines (ISR), deferred procedure calls (DPC), and timer DPCs (DPCTmr). They are different, but effectively all are covered by the low bucket numbers: good, high bucket numbers: bad mantra above.


What next, once you've drawn a bead on a specific driver?
+ Selectively disable suspect devices with device manager to see if your issues get cleared up.
+ get updated drivers for the component if possible.
+ check the hardware behind the driver for performance issues.

It's worth saying--long times aren't a smoking gun here, they are a clue to the real issue. They should be used to narrow down the search field for your cause of your performance issue--it's still up to you to determine the resolution..

Hopefully this is of use to some of you.
the all new rob is offline   Reply With Quote
 

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -7. The time now is 04:17 PM.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.