What is RAAT?

1. Roon Ready hardware devices
   
2. Audio outputs, sound cards, and USB DACs connected to the Server
   
3. Audio outputs, sound cards, and USB DACs connected to any computer or device running Roon Bridge
   
4. Audio outputs and USB DACs connected to Android devices running Roon

Philosophy

Design Goals

1. Support all relevant audio formats today and for the foreseeable future. We don't publish a list of formats that RAAT supports because it is not the limiting factor.
   
2. Stable Streaming over Ethernet and WiFi networks. We take this for granted now, but it's easier-said-than-done, and a huge set of implementation choices are driven by this requirement.
   
3. Modest endpoint hardware requirements. This means endpoints don't have to handle expensive DSP or content decoding--that will happen on the server. This means that many existing devices can add support for RoonReady without changing the hardware.
   
4. Audio devices must own the audio clock. Many other protocols get this wrong, including AirPlay. It's not possible for two clocks to agree perfectly. Letting the DAC control the pace of streaming removes the need for a clock-drift-compensation mechanism that is bound to increase cost, decrease sound quality, or both.
   
5. Tight playback synchronization suitable for multi-room listening. There's a careful line to walk here. If we demand ultra-tight (1-10us) sync, it becomes impossible to implement the system on existing/unspecialized/heterogeneous hardware platforms. We shoot to be within 1ms (and under ideal circumstances often much better), which is more than adequate for multi-room listening.
   
6. Support for new streaming services, file formats, DRM schemes, etc can be supported without a firmware upgrade. In fact, the only reason an upgrade should be required is to fix a low-level bug, or to access more hardware functionality. This is really important. Not all partners/hardware have easy firmware update paths that can be done at home. Our acceptance of this reality has deeply influenced RAAT's design. Just as with Google's Cast devices, the majority of the business logic is delivered to the device at run-time as a script. This means that we are capable of completely re-designing the audio streaming and buffering logic without updating device firmware. This is absolutely critical, since most of the bugs + evolution in a system like this relate to networking, not audio. Other than Cast, we are unaware of another system that is this flexible. 
   
7. Cheap to implement, and easy to distribute. No patented technologies involved. No requirement that manufacturers use technologies that are subject to export restrictions. And Roon provides a high quality, portable reference implementation as a base for customization instead of a pile of documents describing a network protocol.
   
8. Provide a great user experience. This means no stupid 2s delays when touching transport controls (looking at you, AirPlay). It means no too-simple-to-be-good approaches to zone synchronization (looking at you, squeezebox). It means no artificial stream format limitations. It means that the system is flexible enough to allow processing in the server or the endpoint. It means that volume control and source selection works right whenever possible. 
   
9. Promote honesty regarding what is happening to the audio. RAAT is tied to Roon's signal path feature. We work with manufacturers to make sure that potentially destructive processing stages like software volume controls are exposed to interested users, and that processing isn't being concealed or hidden.
   
10. Enforce high-quality user experiences via a certification program. User experience is another core competency for us. We are actively pushing hardware companies to make better user experiences by iterating with them on the product before allowing them to be released. We require parity between RoonReady integrations and other audio protocols offered by the devices, ensuring that Roon support does not become a second class citizen. Another requirement of the certification program is that hardware manufacturers leave devices with us long-term for support and QA.
    
11. Two-way control integration. Artwork and now-playing information can be displayed on hardware devices. Front-panel controls and IR remotes can control Roon via the device. Volume controls on device front panels can be kept in sync with Roon. If you're talking to a device that has multiple inputs, and start music in Roon, the input automatically switches to Roon's input. Anyone who's used Roon's Meridian integration knows the value of this set of capabilities.
    
12. Deeply extensible protocol. We've placed many extension points in the hardware protocol, and in the interfaces between the RAAT implementation and the hardware-specific code. This allows us to easily support more functionality in the future. We fully expect to learn of more use cases as the breadth of hardware that we are supporting grows, and the protocols are designed to get out of the way and scale gracefully. 
    
13. No support for under-specced platforms or un-proven network stacks. RAAT is built to evolve over time. We continue to improve the network protocol. We might decide to change the buffer size requirements on the device to increase stability. We might decide to build a second network protocol optimized for streaming over WAN, or something else like that. We give the same advice for users of Roon as we do to manufacturers building RAAT-based products: under-specced systems lead to bad user experiences; hardware is cheaper than ever and getting cheaper all the time; don't over-economize if you want the best result.