RAAT Details Anyone?

I don’t want to ask for proprietary information, but can anyone explain, in some detail, how RAAT works? I don”t mean metaphorically or what features it offers, but some detail about how it compresses a high-bandwidth music stream. Thank you.


It does not perform any compression. What did you read to lead you to this believe?

I kind of assumed that it had to since it can stream multiple, concurrent, high-bitrate music “files” over Wi-Fi, which normally tops out at about 88.2kHz for a single bitstream.

Thanks, I’ve seen that; but it doesn’t explain how the protocol actually works (perhaps for good reason).

24/88k, 2 channels is about 4.3 Mbps
802.11 n gives 50 - 600 Mbps (Wikipedia)
802.11 ac gives up to gigabit
Plenty of room.

Yes, that’s true; but you have to consider the power of the wireless router(s), their distance from the receiver or transceiver, anything that might insulate the signal, interference, and, of course, the limits of the receiver or transceiver itself, plus how many wireless devices you’re concurrently serving on a typical home network, most of which become far less critical with CAT6 or CAT7 RJ/E cables. So when Roon indicates the following as a design goal of RAAT, “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“, I want to know how they did it. It’s true that I was making the supposition that some kind of compression was involved, and that may be wrong; but I have seen Roon work reliably over Wi-Fi at much higher bitrates than, in practice, any other solution I’ve personally tried. So I want to know, to the extent that it’s really any of my business, how they did it.

Don’t take this as the answer to “how they did it,” as that’s left up to the Roon guys to decide if they want to divulge.

The issue of Wi-Fi isn’t necessarily the available bandwidth nor is is the power of the wireless radio. The real issue is packet size. WiFi uses a fixed-length frame that is somewhat larger than standard Ethernet and there are a fixed number of those frames that can be moved on the network in a given span of time. On top of that the underlying infrastructure is half-duplex. Only one device can talk at a time and at that it can only send or receive. Get a bunch of devices talking in a chatty manner and the network efficiency drops significantly.

The issue with streaming audio is that in most implementations it’s done in pseudo-real-time. The files are large, but they’re metered out over a long period of time so the actual bitrates are relatively small – 24/192 is around 10Mbit/sec. The problem with Wi-Fi comes down to the fact that as a physical / link layer it absolutely SUCKS at small packet transfers. A ton of available bandwidth is wasted with partially-full frames and since in most networks there are multiple devices trying to talk at the same time you run into contention when your audio stream gets put on the back burner in favor of your iPhone collecting Facebook updates.

Think of it this way… in a given amount of time you can transfer X number of Wi-Fi frames. If the frames are stuffed full then you’re going to move a lot of data. If they’re only fractionally full then the network throughput is going to fall through the floor. This is why you can copy that enormous DXD file at high speeds over Wi-Fi, but you can’t stream it without dropouts. With a copy the goal is to get it done as fast as possible. With most streaming implementations you’re at the mercy of metering out the track over the entire time it takes to play it.

So if you want to make Wi-Fi work for streaming audio you need to stuff the packets to be 100% full and send them in such a way that they are making efficient use of the network. This requires a properly-sized buffer on the receiving end and a lot of intelligence as to how that buffer is draining. Streaming high-bitrate audio over Wi-Fi is absolutely possible, but it takes a lot of forethought to make it work reliably.

RAAT has the advantage of being in control of the sender and receiver so that makes the problem much easier to solve.


That makes a lot of sense and contains some information I did not know. Thanks so very much. I see you’re from dCS. I have a great deal of admiration for your Ring DAC. I owned a first-generation Debussy but unfortunately it wasn’t a very good match for my system through no fault of the Debussy. I evaluated a Rossini player with the external word clock when I got my Ayre QX-5 Twenty but, again, the tonal quality did not mesh well with my system. I mean that as no criticism of the Rossini whatsoever.

In a way, and I’m not being pedantic, packing the frames 100% is, in my mind, a form of compression in that you’re making more optimal use of the available space than would normally be done. It’s sort of like only using the maximum number of bits you need to represent a particular value rather than staying on byte or word boundaries with padding. You have to be clever because you don’t want to lose the ability to distinguish between individual values, but it’s plausible. Does thar make sense?

Compression usually includes removing empty space in a file. Zero stuffing a frame is the opposite, a form of inflation if you will. As I understand what Andrew is saying protocols like RAAT don’t compress, they just don’t inflate as much by including more of the file in the frame than the bare minimum.

1 Like

WiFi is OK for RAAT. If you don’t have enough bandwidth you will get dropouts. It won’t compress your music.

One of the (many) problems with WiFi is it’s susceptible to interference. So if another transmitter, like a close neighbors access point, is on the same frequency it can cause dropouts for you.

If you want to use WiFi for hi-rez audio get a good Mesh network or use HomePlug. HomePlug sends the Ethernet packets over the power lines in your home and seems to work great for audio.

Or a microwave oven, some cordless phones, and many security system motion sensors.

I’ve had good luck with these as well, but if you have a turntable in your system you’ll need to be very careful with cable routing as some phono stages can pickup a lot of noise from these things.

If you have cableTV or satellite then MOCA or DECA are worth investigating. They work extremely well.

Yeah, I don’t really like using Wi-Fi to distribute music, although I am doing so with Roon, partly and temporarily, while I run Roon Server on a MacBook Pro until I get a Nucleus+. I live in a fairly small space but have three Apple Airport Extremes linked by Ethernet cables to create one “big ass” Wi-Fi network in addition to the physical CAT6 and CAT7 Ethernet cables that connect most devices in my place. The sheer amount of power put out by the array of three well-distributed routers plus their relative proximity to any one device tends to overcome problems with interference through brute force, but it can’t overcome the inherent limitations of the Wi-Fi protocol, at least not on its own.