# Troubleshooting Audio Dropouts --- ## Overview This document contains information about tracking down and troubleshooting issues that lead to audio dropouts, in particular with RAAT-based outputs, including RoonReady devices, and outputs connected to computers or devices running Roon, RoonBridge, or RoonServer. ## What are dropouts? All RAAT-based zones allow the audio hardware to control the playback clock. A consequence of this is that the playback clock stops for *no-one*. If the playback clock reaches a position in time, and the audio that is supposed to be played is not available, a **dropout** occurs. Instead of holding up the audio hardware to wait for the late-to-arrive data, RAAT outputs replace the missing data with silence and continues with playback. If 3 seconds out of the past 30 seconds of playback consisted of dropouts, Roon moves onto the next track and displays an error message. This behavior is new in version 1.2--so systems that limped through playback with some hiccups in previous releases may be more proactive about identifying the problem and moving on. ## Why do dropouts happen? There are four primary causes of dropouts: - Performance Issues - Hardware Failures - Configuration Issues - Bugs ## Performance Issues These are some examples of performance issues: - The storage device that holds the media isn't delivering it in time - The internet service that holds the media isn't delivering it in time - The internet connection is not fast enough to stream media at this quality level. - CPU usage on the *Core* or *Output* device is too high. - Networking hardware is not performing adequately. One tell-tale sign that you're looking at a performance issue is when the issue gets worse with higher-bitrate streams. If CD-quality content plays fine, but DSD256 is hiccuping, it's probably a performance problem. Dropouts can also happen if your hardware is not in line with [[our recommendations|FAQ: What are the minimum requirements?]]. In this case, there really isn't much to do but upgrade the hardware. Sometimes Roon's support staff can diagnose a performance issue by looking at log files. Other times, it will be clear that a performance issue is occurring because it's affecting apps or devices other than Roon. Tools like Task Manager (Windows) and Activity Monitor (OS X) and `top/iotop/htop` (linux) can sometimes point towards performance issues, too. ## Hardware Failures USB cables go bad. Ethernet cables fail. Routers can be unreliable. Network switches fail. Hard drives fail. RAM goes bad. All of these things can cause problems for Roon. Some of the most vexing failures fall into this category. The general strategy for tracking down hardware failures is by isolating the failure to the smallest configuration possible. ## Isolating Performance Issues and Hardware Failures **Isolating** a problem is the process of finding the smallest configuration that reproduces the issue. This proceeds as a process of elimination. The reason why we isolate issues is to learn something about them. In the ideal situation, the process of isolation ends when you locate one element of your configuration that, when added or removed, causes the problem to appear and disappear. Some of the things that you do when isolating a problem are unrealistic. Sometimes the steps are time-consuming or arduous. But the process works. Some examples of how you might isolate a problem: - Turn off or disconnect devices that don't appear to be related to the problem. - Disconnect the router from the network (unless the problem only happens with internet-based content) - Swap out ethernet cables and switches--if this causes a change in behavior that is a red flag for a hardware failure - If you're using a NAS, try playing content from the local SSD instead. If this changes behavior, it points towards a performance issue with the NAS or your network - If you're using WiFi, Power-line networking, or 100mbit switches, switch to gigabit ethernet--even temporarily--to learn whether those choices are related to the problem. - Reboot machines and devices. If this causes a change in behavior, you've learned that this is a problem that develops over time--which can be an important clue. - Avoid running other software, particularly software that makes significant performance demands or interacts with audio hardware. If this causes a change in behavior, it almost always increases the understanding of the issue. Sometimes this exercise ends by implicating hardware, software, or a device driver. Sometimes it ends with the diagnosis of a bug in Roon, or a hardware device. Sometimes it ends when the configuration is small or simple enough for Roon to reproduce the issue in-house and take it from there. If done rigorously, with patience and discipline, this approach nearly always leads to a satisfying result. ## Troubleshooting configuration issues (RoonReady outputs and other devices) Many devices have their own configuraiton screens--often accessible from a web interface. There may be settings on these screens that are worth tweaking. It can also help to update all devices to their latest firmware, in case the problem you're experiencing has already been fixed. ## Troubleshooting configuration issues (Connected outputs) Some devices or drivers are picky about certain configuration details. This is particularly common with devices that are directly connected via USB and Firewire, and also with software-based drivers. Roon provides a few settings to help tweak your way around device-specific issues. For more information on manipulating audio settings see [[Audio Setup Basics]]. ### Resync Delay The resync delay setting can help when dropouts occur near the beginning of playback. This is particularly useful with drivers that perform faster-than-realtime buffering. Many software-based drivers fall in this category, as well as some products that have unique buffering strategies. If you are having brief dropouts around the start of playback, we recommend trying out this setting at 500ms and 1s and seeing if the issue gets better. ### Use Power-of-2 Hardware Buffer Size (CoreAudio and ASIO only) Some devices are sensitive to the *alignment* of the audio buffers that are passed to them. This setting forces buffers to be aligned to sizes that are powers of 2. This setting is most useful with software based devices and "HD Audio" devices. ### Use Max Hardware Buffer Size (CoreAudio and ASIO only) Some devices are more stable with larger hardware buffers. If you are having issues, it is worth a shot. Note that some devices only support one hardware buffer size. In that case, the setting does nothing. For devices that expose a range of supported values, this causes Roon to use the largest one. ### Buffer Size (WASAPI and ALSA only) This setting allows you to tell Roon to request a specific buffer size from the driver. There is no guarantee that Roon will get the size you ask for, but it will try to choose the closest one. In theory, all devices should be willing to accept any buffer size, but this is not always true in practice. Larger sizes aren't always better! We get the best results in the 25ms-100ms range. ### Use Event Driven Mode (WASAPI only) Event Driven mode is the best way to communicate with WASAPI devices, however not all devices, especially some of the more primitive built-in devices that come with computers, do well in Event-Driven mode. If you are having issues, it might be worth trying with this setting on and off to see if they go away. ## Bugs Sometimes dropouts occur as the result of bugs. Sometimes these are Roon's bugs. Sometimes they are bugs in an internet service. Sometimes the bug is in a device driver, hardware implementation, OS, or even in your NAS. These are the trickiest to isolate and track down. If all else fails, our support staff is here to help. Many classes of bugs in Roon are captured in our log files. Other bugs sometimes show up in operating-system level logs. You can check the Console app (OS X), The Event Log Viewer (Windows) or `dmesg`/`syslog` (Linux) for evidence of system-level trouble.
Page last changed Wed Mar 21 2018