What are the known software Issues and possible solutions?

This section discusses some software-related issues discovered in the past and provides some tips on problem analysis and possible solutions or workarounds. Note that the discussion in this section applies to scenarios where the driver has been configured for low audio latency (see also FAQ on compatibility and stability issues).

(1)  Kernel Mode Processing (background info)

A USB audio driver must be able to process incoming and outgoing isochronous data streams in real time. The driver gets called periodically by the operating system kernel to perform its processing. The period of the calls is determined by the buffer size the driver uses to exchange data with the USB. This buffer size is adjustable and is referred to as “Streaming Buffer Size” or “Streaming Buffer Depth”, If one of the processing calls is delayed by more than one buffer size interval, data loss will occur. Delayed processing calls are the most common source for audible signal distortions. This problem is referred to as DPC latency issue. Deferred procedure call (DPC) is Microsoft’s term for processing callbacks issued by the kernel. In this context, “DPC latency” is not to be confused with audio latency which is not directly related. Because Windows is not a real-time operating system the Windows kernel cannot guarantee that a driver gets called in time. Any kernel-mode software component, including other device drivers, can monopolize the CPU which prevents the kernel to perform its periodic processing in time. A typical situation is that a device driver gets called by the kernel (e.g. from a timer service) to check the state of its hardware. The driver keeps the CPU busy for several milliseconds by spinning in a loop and polling hardware status, for example. The kernel cannot call any other driver before this driver returns control. If the misbehaving driver keeps the CPU busy for an interval that exceeds the streaming buffer depth of the audio driver, the audio driver experiences a delayed processing call which leads to an interruption in the audio data stream. Note that at this level of kernel-mode processing there is no priority based multithreading. The Windows kernel executes calls into various device drivers sequentially which may lead to delayed calls as described above. The design is based on the assumption that no driver stalls the CPU and any call into a driver returns quickly. Microsoft documentation states that drivers should spend no more than 100 microseconds in any processing call issued by the kernel. While most device drivers fulfill this requirement there are a couple of misbehaving drivers in the market. If such a driver is used in parallel with an audio driver then audio dropouts can occur. Note also that a multi-core CPU is not a solution to the problem. This is because the kernel (and bus drivers) arbitrarily assigns kernel processing calls (DPCs) to CPU cores. A device driver cannot reserve a CPU core for its own (time-critical) processing.

(2)  Misbehaving

This section lists some potential sources of DPC latency issues. The information is based on AMI’’s own experience and on user feedback.

1)    W-LAN or Ethernet device drivers

Quite often it can be observed that device drivers for W-LAN adapters monopolize the CPU in kernel mode as described in the previous section. A few Ethernet drivers do also have such issues. AMI’s dpclat utility (see next section) can be used to analyze the system behavior when WLAN is enabled or disabled.

Solution: Try to find an updated W-LAN driver, or try an older version of the driver. If no suited driver can be found, disable W-LAN (or Ethernet) while audio streaming is running.

2)    On-access virus scanners or personal firewall software

Normally, this kind of software includes some kernel-mode component to perform filtering or scanning work in the kernel. Often, such components keep the CPU busy for long periods which causes kernel processing calls (DPCs) to be delayed. AMI’s dpclat utility (see next section) can be used to analyze the system behavior when on-access scanning (or filtering) is enabled or disabled.

Solution: Disable or uninstall the software. Try using a different product with similar functionality.

3)    Windows in-box drivers

Basically, it can be stated that the set of device drivers that ships with Windows behaves well. If DPC latency problems occur then they are typically caused by third party drivers that are to be installed for hardware which Windows does not support by default. So if a hardware component is supported by an in-box driver then this driver is to be preferred and a third party driver should not be installed.

4)    WHQL signed drivers

The fact that a given third party device driver is WHQL certified is not a guarantee for correct DPC runtime behavior. WHQL tests currently do not enforce proper DPC behavior.

(3) DPC Latency Checker Utility

Thesycon (AMI MUSIK DDH-1’s original driver provider) provides a free utility that enables users to check the behavior of a given system. The utility performs a statistical analysis of kernel-mode processing calls which are called deferred procedure calls (DPC). For more information about the utility checkout

http://www.thesycon.de/eng/latency_check.shtml

To download the utility directly, use this link:

http://www.thesycon.de/dpclat/dpclat.exe

 

The dpclat utility should be executed when the audio device is not connected to the system. The utility shows the maximum delay of processing calls the audio driver may experience on the given system. If excessive DPC latencies can be observed then try to identify the culprit by using a trial and error approach. Disable/Enable devices in Device Manager (one at a time) and check whether the results shown by dpclat change. Unfortunately, dpclat does not allow to identify the kernel-mode component that is causing the problems directly. This is because this kind of analysis is very difficult to implement

Posted in .