In the previous chapter, we talked briefly about protocols. What are they and what exactly does it matter? That’s hard to explain in simple language, but we’re going to try. We’re also going to list the most commonly used protocols for you.

UPnP

UPnP stands for Universal Plug and Play and is intended for automatically configuring network devices. UPnP is actually a collection of protocols. UPnP uses a form of multicast (data from one device to many on the network) and unicast (one-to-one communication) to find and configure devices.

So basically, the protocol allows for automatic device recognition and configuration, with other network devices also knowing what a device can do and how to work with it.

So in the case of audio, after connecting to the network, a media server sends out what it can stream and how (UPnP compatible) streamers can connect to the server.

DLNA

DLNA is actually an extension of UPnP. It works no differently at its core, but has more to do with an industry alliance that has established what devices must support in order to bear the DLNA logo. Under the hood, it’s just UPnP.

Airplay

Airplay was developed by Apple. The protocol can stream audio, video, photos and displays (screen-cast). Airplay is in all Apple devices and is also often implemented by other manufacturers to be compatible with other Apple devices.

Apple uses UDP for streaming media and then RTSP (real time streaming protocol). Obviously with some modifications of its own. A form of multicasting is also possible (from one source to multiple players

). For that, Apple uses its own RAOP: Remote Audio Output Protocol.

Apple uses the Apple Lossless codec for streaming audio. However, even with Airplay2, this is limited to 16 bit / 44.1 kHz. (2023).

Google Cast

Google Cast is a development by – not entirely surprisingly – Google. It can basically do the same thing as Airplay: share audio, video, photos and screens (screen-cast). Like Airplay, Chromecast is often built in by third parties to be compatible. It is even used by some manufacturers as the basis for the streamer.

The Google Cast protocol is quite different from Airplay. Now we won’t go into detail here because it would get way too technical, but let’s just say that Google Cast is a lot more flexible. That’s nice for developers.

Not much can be found about the exact protocol, except for highly technical information found in SDK – Software Developer Kits. The bottom line is that for finding players MDNS – Multicast DNS – is used. For streaming itself, a custom protocol is used, developed by Google itself: it is completely closed.

Google Cast can stream high-res audio up to 24 bit / 96 kHz. It can also handle 4K video. Qualitatively, then, it is a somewhat more interesting system than Airplay.

RAAT

Roon uses RAAT: Roon Advanced Audio Transport. Besides RAAT, Roon can also handle Sonos, Airplay, Chromecast and SlimProto (Squeezebox).

According to Roon, RAAT provides reliable data transfer as well as a plug and play experience with all certified streamers and dacs. Because of the mandatory certification process, Roon recognizes which device is connected and thus knows what the device can and cannot do. This is particularly convenient for the end user, as they don’t actually have to set anything up after connecting and activating the device.

Diretta

Diretta is a niche protocol. But it is a particularly interesting idea the developer has. Diretta focuses on a constant flow of data without “bursts” as is the case with many other protocols (buffer fills and then pauses). Diretta believes that a constant flow sounds better because it allows the controller to work more quietly. And therefore less is asked of the hardware, power supply, and the rest of the (audio) chain.

SonosNET

Sonos is one of the best-known players in the market. The brand uses its own protocol to interconnect players and talk to the controller (app). Sonos also uses its own SonosNet (a mesh system to interconnect players) to ensure a stable experience. The combination of its own streaming protocol AND its own mesh system ensures that Sonos operates stably and reliably in many cases.

Sonos can handle high-res audio, but does not always play at maximum quality. For now, 24bit / 48 kHz is the maximum quality for newer products. Older models play either nothing, or 16 bit / 44.1 kHz.

BluOS

The BluOS system and protocol is a technology initially developed for Bluesound. A system developed by Lenbrook. Lenbrook still includes NAD and PSB, among others. However, brands such as DALI and Lyngdorf are also – indirectly – linked to it. It is therefore not surprising that NAD makes intensive use of BluOS and also active DALI speakers get these modules built in.

SlimProto

Squeezebox uses SlimProto; the successor to SLIMP3. Even after all these years, we still see the Squeezebox / SlimProto system in certain configurations. There are groups that swear by the custom (TCP-based) protocol. It works stably and sounds good. And it is open-source, allowing lots of developers to work on it!

Rounding up

There are undoubtedly other protocols. Consider systems used in the studio: Ravenna, AES67, Dante… But these are hardly used in consumer systems, if at all. Therefore, we do not cover them here. The above protocols cover 90% of the industry.

It is important to think carefully before stepping into an ecosystem. What do you have in place? Do you want to expand? What would be any costs involved? After all: an additional zone via Chromecast has a different price tag than an additional Aurender!

Overview of protocols and systems

* Often it is listed as compatible, but then it only works via Airplay or Chromecast. Know that this does not give optimal sound results.