This article applies to Qu and ZEDi series mixers only.
System requirements and instructions for the Windows USB Audio Drivers are specified in the driver Help Manuals. This is available from the driver section of the product Software pages.
For USB audio streaming to work reliably, the computer must be able to process incoming and outgoing isochronous data streams in real time. This might not be the case even though the PC fulfils the system requirements - there is always a risk that hardware and/or software issues will cause problems.
Compatibility and Stability Issues
USB audio devices have greater requirements for USB hardware and software layers than other USB devices. Due to the real-time nature of USB audio streams there are also requirements for the time characteristics of the operating system and third-party software components installed on the system. Software components that impact the real-time behaviour of the operating system are not compatible with audio streaming applications in general. However, in this context it is 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 headphones) then the operating system must be able to handle the timing requirements of the driver and issues can occur otherwise. If audio latency is not critical (e.g. in case of music playback) then the timing requirements of the driver are relaxed, which increases compatibility with other applications and drivers significantly.
The Windows USB Audio Driver allows users to adjust internal buffer depths to find a trade-off between audio latency and compatibility with a given system.
Possible hardware issues
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 a USB audio device can work only if the 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 kinds of devices are much more tolerant with respect to USB signal distortion. For this reason, it is 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 these kinds of problems.
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.
PCB mounted USB ports - 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.
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.
Possible software issues
The driver is 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 (USB Streaming Mode). 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 call-backs 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 will be called in time. Any kernel-mode software component, including other device drivers, can monopolize the CPU, which prevents the kernel from performing its periodic processing in time. A typical situation is that a device driver is 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 multi-threading. 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 fulfil 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 assign kernel processing calls (DPCs) to CPU cores. A device driver cannot reserve a CPU core for its own (time-critical) processing.
Some potential sources of DPC latency issues are listed here.
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 also have such issues.
Solution: Try to find an updated W-LAN driver or try an older version of the driver. If no suitable driver can be found, disable W-LAN (or Ethernet) while audio streaming is running.
Anti-virus 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.
Solution: Disable or uninstall the software. Try using a different product with similar functionality.
Latency Checker Utilities
There are a couple of free utilities that enable users to check the behaviour of a Windows system. These perform a statistical analysis of kernel-mode processing calls. They should be executed when the audio device is not connected to the system. If excessive DPC latencies are 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 change.
For more information:
LatencyMon http://www.resplendence.com/latencymon
FAQs
Why is the ASIO Buffer Size dependent on the USB Streaming Mode?
Because the ASIO buffer layer is driven by the USB streaming layer.
ASIO can work without dropouts only if the following condition is met: ASIO buffer size (in ms) >= USB streaming buffer depth (in ms)
By convention the ASIO buffer depth is specified in terms of samples which creates another dependency on the sample rate. For example, if USB Streaming Mode is set to Standard then the minimum ASIO buffer depth is 4 milliseconds which corresponds to 192 samples at the Qu sampling rate of 48 kHz. Usually, an ASIO buffer size that is a power of two is preferred. In most DAWs sample processing is more efficient if such an "even" number is chosen. So, in the above example we round up to the next power of two and end up with 256 samples.
The control panel allows the user to pick one of the power-of-two numbers between 64 and 4096 and then checks if this works with the current USB Streaming Mode setting. If the selected ASIO buffer is too small for the current setting, then the control panel displays a warning message. In this case the user should pick a larger ASIO buffer size value.
Can I change the WDM Buffer Size?
Windows uses a separate buffer layer to exchange sample data with the driver. This is done through the so-called WDM interface which is the basis for all other Windows sound programming interfaces such as MME, DirectSound and WASAPI. The size of the WDM buffers is defined by Windows or the application that is using one of the above programming interfaces. The driver does not provide a means to adjust the WDM buffer size, thus the latency that is achievable through WDM depends on the USB Streaming Mode setting AND the WDM buffer size selected by Windows or the application itself.
Why do I need a PC manufactured after January 2006?
The driver uses isochronous transfer mode to transfer the audio signals through USB. Early USB implementations and chip sets did not support isochronous transfer mode correctly, therefore it is necessary to define minimum chip set requirements. As it may be difficult for users to find out the chip set model, the system requirements specify the age of the computer instead.
Can I remap WDM outputs to specific USB outputs?
No, this functionality is not supported.