· Introduction

· Supported OS

· How to use

· What's new ?

· In-depth latency tests

· FAQ

· Professional Edition

· Download Home Edition

· Buy Professional Edition


Using LatencyMon

Starting and stopping LatencyMon

When LatencyMon starts, it will display a message to click the Start button to start analysis. Click the start button. The page under the Main tab will give an overview of the most important information. A detailed report is available under the Stats tab. When you are done click the Stop button.





Report view

The report view displays a conclusion of the suitability of your system for playing real-time audio at the top. If the execution times of all DPC and ISR routines stay below 2000 µs (microseconds), your system is considered suitable for handling real-time audio without dropouts. If some routines have execution times between 2000 µs and 4000 µs, your system is considered doubtful. If ISR or DPC routines are detected to execute for longer than 4000 µs, a system is considered unsuitable for handling real-time audio. Note that these numbers are just chosen arbitrarily. For optimal midi to audio latencies, buffer sizes of a sound card and driver should be set to very low values then only very low execution times of DPCs and ISRs become acceptable.

The report view will display:

  • highest measured DPC execution time
  • the driver that was executing the longest executing DPC routine
  • frequency of DPC executions (divided in execution time categories)
  • highest measured ISR execution time
  • the driver that was executing the longest executing ISR routine
  • frequency of ISR executions (divided in execution time categories)
  • highest measured hard pagefault resolution time
  • the process in which the hard pagefault occurred that took the most time to resolve
  • frequency of hard pagefault hits




    Selecting CPUs

    On a multi processor system, LatencyMon offers the option to exclude one or more CPUs from being measured by selecting them from the options menu. For a complete analysis you should select all available CPUs. This feature may be useful to check which CPUs are connected to interrupts and verify how ISRs and DPCs are distributed among available processors. Also it may allow you exclude certain processes to which you have assigned a certain affinity.




    High DPC or ISR routine execution times: how to proceed

    If LatencyMon reports the DPC and ISR execution times to be too high, you should take a look at the responsible drivers. It may be that these drivers belong to a device that is non-critical for the operation of your computer. If for example tcpip.sys or ndis.sys is reported as the culprit, chances are the problems are caused by your wireless network adapter, if you have one. You could consider disabling the WiFi adapter and receive internet via an Ethernet cable. You can disable devices by right-clicking on My Computer and selecting Device Manager, right-clicking a device and selecting disable. You should run LatencyMon again to check if the situation has improved, there might still be another device or driver causing audio latencies.

    Note that if high latencies have been reported to be caused by drivers which are critical for the operation of your computer such as motherboard drivers, there may be nothing you can do to get your computer suitable for processing real time audio.




    Hard pagefaults: how to proceed the investigation

    We believe that hard pagefaults are the most common cause of audio dropouts. The effect of a program hitting hard pagefaults while playing audio is usually dramatic. One problem with pagefaults is that they often come in groups so that a row of pagefault causes interruption of the audio stream. Another problem with them is that unlike ISRs and DPCs, putting in more processors into a system will not help you to avoid them. Page faults need to get resolved immediately and any thread that hits them is suspended until the pagefault is resolved. Hitting a hard pagefault on a page file or memory mapped file that is backed on a drive that is spun down because of a power feature may interrupt a program for several seconds until it can proceed.

    If hard pagefaults are reported but no high DPC and ISR execution times you should investigate if these are the cause of audio dropouts. The difficulty with pagefaults is that they are common to occur so it's hard to find out if they are the cause of audio dropouts and stutter. In order to find out if pagefaults are the cultprit you need to know that the pagefault occured in the process responsible for producing audio and also while it was producing audio.

    To verify that the hard pagefault occured in your audio program, take the following steps:

  • Stop the monitor by clicking the stop button
  • Click the Processes tab
  • Now click on the Number of pagefaults column so the view gets sorted
  • Now look for the process name of the audio application that was running and see if it was hit

    Hard pagefaults should only be considered a problem if you can hear they are actually interrupting the audio stream. It is common for any program which uses a lot of memory to hit hard pagefaults. By observing the Processes view while audio is playing you can find out if hard pagefaults are being hit while audio is playing. If you found out that pagefaults are the cause of audio dropouts you should read the next section on how to avoid them.




    How to avoid hard pagefaults

    If you have concluded that hard pagefaults are the cause of audio dropouts, you can do any of the following to resolve the problems:

  • Close down unnecessary applications which consume a lot of RAM
  • Close down unnecessary service applications which consume a lot of RAM (the Search Indexer service is notorious)
  • Increase the amount of RAM in your system
  • Increase the working set of the audio application, only an option if you are the author of the software.
  • Make sure audio data is paged-in (resident). Pages of memory are swapped out based on their use counts. If you use Windows for live playing, do a silent run of your software synthesizer. After changing patch on a sampler, touch all keys so that all memory it uses is paged-in to avoid embarrasing scenes.
  • Disable the pagefile altogether. You can disable the pagefile by right-clicking My Computer and selecting Advanced System Settings->Advanced->Performance Settings->Advanced->Virtual memory->Change. Note that if you have no pagefile, the system can run out of memory if not enough memory is available. Also the system will no longer create crash dump files in case of a system crash.




    Other causes of audio dropouts, pops and clicks

    This section summarizes a list of other possible causes of audio dropouts, clicks and pops. If there are no high DPC or ISR execution times reported and hard pagefaults are not the cause of the problems you should consider these.

    Audio buffer sizes
    To reduce midi to audio latencies (that is the time between a key press on a MIDI keyboard and the occurrence of the actual sound), the audio buffer size of the audio driver should be as low as possible. But it must be supportable by the system. The acceptable limit of 2000µs for DPC and ISR execution times has been arbitrarily chosen. The lower your audio buffer size, the lower the tolerance for long execution times of DPC and ISR routines and page fault resolution. In order to retain a system that does not drop out you may need to increase your audio buffer size. So it might be that your system is not suitable for low midi to audio latency but you might still be able to find an acceptable balance that works.


    CPU overloading
    If a software synthesizer or effect requires too much execution time to compute its audio buffers in time it will cause stutter, clicks or pops. This can for example easily happen when playing too many voices or too many virtual instruments at the same time in a software synthesizer.

    Thread Contention
    If there are simply too many threads competing for CPU time an audio program may not get enough attention from the scheduler to process its audio buffers. Threads are selected based on a priority scheme but if there are multiple programs running with threads running at high priority, there may just be not enough CPU time available for the audio software to fill its buffers in time. Threads responsible for producing audio normally run at highest or real-time priority. Competing threads with a lower priority may still get scheduled because the balance set manager which is part of the operating system will boost threads with a lower priority to avoid thread starvation. Closing down unnecessary programs, services and getting more CPUs will help you.

    Bugs in audio software
    Bugs in audio software can of course create all sorts of artifacts including pops and clicks. If problems are limited to one particular audio program or plugin, chances are it's the program's fault. It also deserves mentioning that exception handling requires a lot of processing power and causes interrupts to occur on the processor on which it's running. A very common example is an audio plugin program which does not mask off floating point exceptions so that each division by zero or other forseeable problem causes an interrupt to occur.

    Bugs in hardware or audio drivers
    Bugs in hardware and audio drivers may also be responsible for causing stutter, pops and clicks.






    LatencyMon documentation and articles

     · Introduction
     · Supported Operating Systems
     · Professional Edition
     · What's new ?
     · FAQ
     · How to use LatencyMon
     · CPU Power Management issues
     · Interrupt to user process latencies
     · In Depth Latency Tests
     · SMIs and CPU stalls
     · Technical information
     · "Windows and Real-time", guest article for kernel developers published by OSR


    Note: this content is currently being updated.


    Copyright © 1997-2024 Resplendence Software Projects. All rights reserved. Privacy Policy.
    Page generated on 3/19/2024 3:03:28 AM. Last updated on 9/16/2023 7:49:04 AM.