What's the difference? RAAT vs AirPlay

(Bill) #1

Is there a good whitepaper or forum post on Roon Advanced Audio Transport (RAAT)?

Why should users consider RAAT over Apple’s AirPlay*? Low latency 24bit PCM and DSD Audio?

*Besides the fact that the Apple Airport Express plays (limited) 16 bit 44KHz PCM and the AppleTV 2, 3, and, maybe 4(?) that resamples in device from 44KHz->48KHz.

RAAT and clock ownership
(Jeff) #2

I think that’s pretty much why. If you have, or want to listen to true high resolution files, then Air Play falls short.

1 Like
(Andrew Cox) #3

I also found streaming to an Aries with AirPlay slow to respond. RAAT is snappy.

1 Like
(Bill) #4

I like snappy. :sunglasses:

(Brian Luczkiewicz) #5

I wrote up a white-paper for manufacturers a few months ago, but it was a little bit sparse in some areas. So here, I’m expanding it and filling in the gaps with more explanation. There’s some light compare/contrast with AirPlay in here, but I didn’t make that the focus of the writeup.

Architecture

Well-architected systems give better user experiences. They work better in the short and long term, and they surface fewer unexpected limitations down the road as the world changes.

AirPlay started its life as a feature of the AirPort Express. It evolved into an audio distribution system a few years later. It is hobbled by trying to fit into the performance envelope of the embedded devices of yesteryear, and it’s cobbled together–a mishmash of hacked up versions of several well-known protocols, with very little coherence to the overall system design. It looks like what it is: an overgrown feature masquerading as infrastructure. It’s stretched pretty thin, at this point, and it hasn’t evolved in a long time.

RAAT has an advantage: it is 10-30 years younger than the bits+pieces that make up AirPlay. We can see not only where the world has gone, but, one level up, what types of change have taken place. We are in a great position to do a better job.

Also worth mentioning: designing network protocols for transporting audio is a core competency of ours. I did the protocol design for RAAT, but this isn’t my first time, it’s my third. The last protocol I built handles all of the networked audio distribution for Meridian’s products, and the one before that handled audio distribution for Sooloos products up until about 2010. There is no substitute for the experience of actually putting something like this into production in the real world.

RAAT is plumbing. It gets the audio from point A to point B without screwing it up, and without bringing limitations to the table that might compel the software/hardware on either side of it to screw things up. It’s an enabling technology for “doing things right” everywhere else in the system. Otherwise, it shouldn’t get in the way.

Design Goals

  • 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. RAAT is already built to handle multi-channel, and 32bit content. Once Roon supports them, RAAT will too.

  • Stable Streaming over Ethernet and WiFi networks. We take this for granted in 2016, but it’s easier-said-than-done, and a huge set of implementation choices are driven by this requirement.

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

  • 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 quality or both.

  • 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/heterogenious hardware platforms. We shoot to be within 1ms (and under ideal circumstances often much better), which is more than adequate for multi-room listening.

  • Support for new streaming services, file formats, DRM schemes, etc can be supported without 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.

  • 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 provides a high quality, portable reference implementation as a base for customization instead of a pile of documents describing a network protocol.

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

  • Promote Honesty regarding what is happening to the audio. RAAT is tied to Roon’s signal chain 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.

  • 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 purposes.

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

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

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

18 Likes
"Now Playing" display on RoonReady audio endpoints?
RAAT and clock ownership
Before you start
"Now Playing" display on RoonReady audio endpoints?
Why does roon not support any and all streamers?
(Andrew Cox) #6

Thanks Brian, very helpful and informative !

(Bill) #7

That is was I was looking for, you delivered the goods!

(Joe Burger) #8

Thank you very much for that post. That really helps explain both were you are and the forethought you have given to where you want to be.

1 Like
(David Watkins) #9

I’m almost convinced, but RedBook sent to my $69 Apple TV supplying my dac via a 12 foot electrically isolated optical cable or my airport express outputting analog to my back porch amp and speakers for ~$90 has a certain appeal. The cheapest endpoint I see is the Sonore Sonicorbiter SE for ~$300 and it will still require a DAC. I hope you don’t price me out of the market by requiring me to buy $1000 worth of equipment for every endpoint. I can’t even use old mac laptops as endpoints at this point.

#10

compare it with Sonos?

(David Watkins) #11

Room is a great user experience. I just don’t want it to be any more expensive than it has to be. Keep it cheap and it will dominate the format. Make it expensive and it will be just another niche product to be copied by someone else in a cheaper version.

(Nick Baker) #12

Or look a little harder and find this all in one endpoint Pi-DAC+; WiFi image?

(David Watkins) #13

That’s cool but I don’t need a new hobby programming raspberry pi. Besides, my local RadioShack has closed down.:disappointed:

(Peter Wright) #14

No programming required, you just download an ISO and write it to a micro SD card. There are easy to find utilities to do the writing.

(Bill) #15

Sonos and Apple Airplay, wired or wirlesss, are two technologies that produce very similair results. Further, they appear to have similair limitations that are described by the Roon engineers throughout the support forum.

Personally, I like Apple Airplay and Sonos’ “Audio Protocol.” In the case of the latter, I get the perception that neither Sonos would open themselves up to Roon, or vice versa. Each product has an advanced interface that allows the user decide what’s best for them. Yes, I think, it would be “cool” if there was the option for a Sonos Endpoint.

To Gentleman that espouses the Raspberry Pi and custom .ISO; that is great free and open solution that puts the advantage in the user. I hope that some manufacterure of gear doesn’t take the Raspberry Pi with Custom .ISO and put a fancy case with powersupply on it then sell it at much higher price. That “ruins” the fun for me, :wink: :smile:

(Andrew Cox) #16

IQAudio are about to be RoonReady, there is a section and thread here. They have indeed taken a Pi, and added a fancy case and a DAC to make an endpoint. Only thing is they’re selling them for a quite reasonable price. Someone should tell them to increase it …

(Peter Wright) #17

Better talk to Bryston then, they just announced a network player based on a Pi and a HifiBerry DAC board.

It has a nice little display and will be less than half the price than their current $3000 box. Mind you this is a network device and still requires a DAC. Quite the bargain (sarcasm fully intended).

The beauty of the Pi and other little computers is they are cheap and good quality. The hardware in the Bryston box probably is worth about $200. I doubt they will selling for that kind of price.

The HiFi world is getting sillier each year… :frowning:

1 Like
(J) #18

shhh… :no_mouth:

(Bill) #19

Oh I know, I said it “tounge in cheek.” Its a way to make money, let the free and open community do the work, dress up the pig and put lipstick on it.

(Robert Brace) #20

I found a really cheap but good endpoint. There are a variety of them on the marklet, in the US Amazon sells these for $35. Supports airplay has a Wolfson DAC and a SPDIF output. Plenty good enough for the systems in my workshop, kitchen and office. Using a QNAP 453 with linux as the server and android phones/ipad/mac as the head end. Great system!

2 Likes
Chromecast Audio as endpoint? [Delivered; B333]