DDH Driver Documentation

  1. What are the supported Operating Systems?

The AMI Muse DDH Driver supports the Windows operating system versions listed below. The driver and its installer have been tested on these systems.

  • Windows XP with SP3 (32 bit)
  • Windows Vista with SP2 (32 bit)
  • Windows Vista x64 with SP2 (64 bit)
  • Windows 7 (32 bit)
  • Windows 7 x64 (64 bit)

The minimum supported OS and service pack level is Windows XP SP3. Any older Windows version or service pack level is not supported as before XP SP3 there are issues in the Microsoft USB bus driver stack which can cause problems. AMI will test compatibility of the driver with any future service pack releases for one of the operating systems listed above and will release an updated driver, if required.

Windows on Apple Hardware

AMI supports Windows installed on PC hardware only. While it is possible to install Windows on a (Intel based) Mac this is considered a very specific use case which is not tested by AMI.

  1. Minimum Hardware Requirements

The USB Audio class uses isochronous transfer mode to transfer the audio signals on USB. Early USB implementations and chip sets did not support isochronous transfer mode correctly and had a couple of other issues. Therefore, it is necessary to define minimum chip set requirements. However, most users don’t know which chip set is inside of their PC or laptop and it may not be easy find out this. Hence, it makes sense to define a limit for the age of the computer. Based on this AMI defines the minimum PC hardware requirements as follows:

  • PC or laptop manufactured after January 2006
  • Intel Core 2 @1.6 GHz, or AMD equivalent
  • 1 GB main memory

It is important to note that there is no guarantee that USB based audio streaming works on any PC that fulfills the above requirements. Because there are so many different PC configurations there is always a risk that hardware and/or software issues will cause problems. Some examples are given in the next section.

  1. Compatibility and Stability Issues

USB audio devices have stronger requirements for USB hardware and software layers than other USB devices. A faulty hardware component, e.g. USB cable or USB port, may not have an impact on standard USB devices such as a FLASH drive but can be catastrophic for a USB audio device. USB hardware requirements are discussed in more detail in the section 4. Due to the real-time nature of USB audio streams there are also requirements for time characteristic of the operating system and third party software components installed on the system. Software components that make real-time behavior of the operating system worse are not compatible with audio streaming applications in general. However, in this context it’s important to note that real-time requirements depend directly on audio latency requirements. If low audio latency is required (e.g. to create a monitor mix in the PC and route it back to speakers) then the operating system must be able to fulfill resulting timing requirements of the driver. If audio latency is not critical (e.g. in case of music playback) then timing requirements of the driver are relaxed which increases compatibility with other applications and drivers significantly. AMI Muse DDH-1 driver allows users to adjust internal buffer depths to find a tradeoff between audio latency and compatibility with a given system. Below, two typical scenarios are discussed.

  1. Low-latency applications

Audio latency is critical if an audio signal is routed into the PC, processed in the PC and then routed back to speakers. A typical scenario is a monitor mix created by a multi-track recording application such as Cubase. For such applications the drivers streaming buffer depth should be set to 4 milliseconds or less. In this configuration a couple of issues can occur because the given system may not be able to handle the resulting real-time requirements. A discussion of possible problems and incompatibilities is given in section 5.

  1. Normal-latency applications

In case of a playback-only or recording-only scenario, audio latency is not critical. For such applications the driver’s streaming buffer depth should be set to 16 milliseconds or more. This will reduce the risk of audio distortions caused by other software components in the system significantly. Issues discussed in section 5 may still occur but this will happen in extreme cases only. If the driver is configured this way, it will be compatible with a larger number of Windows systems. Normally, it will not be necessary to optimize a system for audio steaming according to the hints given in section 5.

  1. Know Hardware Issues and Possible Solutions

This section discusses some hardware-related issues discovered in the past and provides some tips on problem analysis and possible solutions or workarounds.

USB Signal Quality

Isochronous transfer mode uses error checking but no retransmission in case of CRC errors. Electrical noise on USB signals causes CRC errors and thus data loss. This leads to audio signal distortions (clicks). This means that an USB audio device can work only if USB signal quality is good and no CRC errors occur. Most other USB device types (e.g. FLASH drive, printer) are based on bulk transfer mode which uses automatic retransmission in case of errors. These kind of devices are much more tolerant with respect to USB signal distortion. For this reason, it’s possible that a mouse, keyboard, FLASH drive, printer etc. works well on a given USB port using a given cable while an audio device does not work with the same port or cable.

Below is a list of possible sources for this kind of problems.

  1. USB cables

Quite often the USB cable (or its connectors) is the cause for USB signal distortions. Some cables available in the market are not suited for USB 2.0 high-speed communication (480 Mbps). Also the maximum allowed cable length of 5 meters should not be exceeded.

Solution: Try using a different cable. Try a shorter cable (less than 2 meters).

Tip: Stay away from special USB cable offerings optimized for audio, or cables which include additional functionality such as status LEDs.

  1. PCB mounted USB ports

AMI found that on some PC main boards (or laptops) signal quality of some USB ports is insufficient for isochronous streaming. The cause could be that on the PCB USB signals are routed close to a switching voltage regulator, for example.

Solution: Try using a different USB port to connect the audio device.

  1. Front panel mounted USB ports

External USB ports (mounted on a front panel or elsewhere in the PC case) are a possible source of USB signal distortion. Quality of cables or connectors used to connect the external USB port with the main board could be insufficient, or internal cables are placed close to the power supply or other sources of electrical noise.

Solution: Try using a USB port that is mounted directly on the main board.

  1. Know 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 section 3).

  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.

  1. 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.

  1. 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.

  1. 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.

  1. 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.

  1. DPC Latency Checker Utility

Thesycon (AMI Muse DDH’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


To download the utility directly, use this link:


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