I do not listen to music all the time, but I sometimes want to do it anywhere in the home: dining room, studio, bedroom, kitchen…​ Also, I have accumulated so many tracks over years that they are too many for a mobile device. And I don’t always want to use headphones.

I need audio sources in several places in the house, accessing the same music store.

Mobile devices (phones, tablets) with tactile screens, and WIFI networking are now everywhere in the house (and in our pockets), and make ideal remote controls.

Small, silent, low power, and very inexpensive computers are also commonplace (the ubiquitous Raspberry PI, and other similar ARM-based single board computers). They either have correct audio capabilities or can be connected to appropriate converters, to be plugged behind the stereo or a pair of powered speakers.

Taking advantage of all this to implement an audio network is an evidence, but several software approaches exist, and choosing between them is not obvious.

I have been playing with a number of solutions in the last few months (or reading about them in some cases).

So here follows some of my newly acquired net audio wisdom. My main objective is to play music stored on the local network, but there will be some mentions of integration with streaming services (e.g. Spotify, Qobuz, Tidal…​).

The building blocks

There are four building blocks in a network audio solution:

  • An audio File/Data server stores the (bulky) audio data and makes it available to clients using an appropriate protocol (NFS, SMB, HTTP, etc. depending on client).

  • The directory/tags manager extracts audio tags from the files (usually accessing them directly or through a network file sharing protocol), and builds a database used for searching or browsing the collection.

  • Audio players (renderers) take encoded audio data and actually make sound, using some kind of DAC (Digital Analog Conversion) device, such as an internal or USB sound card.

  • The remote control (control point) sits in your hand (or it’s the PC in front of you). You use the application which runs on it to choose songs from the database and control the playback. It interacts both with the tags database and player parts (usually not with the file server, except maybe to fetch cover art).

Depending on the kind of software, some of these parts can be combined.


Online ('cloud') commercial streaming services can be considered another building block to supplement the local music server, but they introduce specific problems, because of Digital Rights Management (trying to prevent you from accessing what you have not paid for or from copying the streams).

But is it gapless ?

This is a relatively small issue, but people are very sensitive to it, it is important from some music pieces (Goldberg variations with gaps: not nice) and you will hear about it all the time if you read forums, so, a quick explanation follows:

Some music tracks need to flow into each other when played consecutively, for example tracks on some live albums (the background noise from the audience never stops), or some classical music pieces.

When playing from separate audio files, it is not trivial for a renderer to ensure a seamless flow: the audio hardware has an input pipe which must be kept full at all times, else it will stop, and a period of silence will ensue: not gapless !

To avoid this, the renderer has to know in advance which file it will process after the current one, so that it can begin filling the audio pipe with data from the next track before it empties when the current track finishes.

There are two ways that this can be achieved: either the renderer is also in charge of the play queue, so it knows the whole sequence all the time (e.g. MPD, OpenHome, …​), or the controller indicates the next track to the renderer before the current track finishes (e.g. UPnP SetNextTransportURI).

The families

There are a number of networked digital audio solution families, they are discussed further down.

In the following comparisons, you should know that I am strongly biased towards open-source solutions, because they preserve your freedom to either change or go-on with a solution without being constrained by what a vendor decides to do.


A nice closed integrated solution, including both network (servers, streamers) and audio hardware (amps and speakers) relatively expensive, very proprietary (can’t even play music from a DLNA server…​). They were among the pionneers, but my opinion today would be: it’s 2016, why bother with a closed proprietary system with no compelling advantages ?

Also you should remember that, as comfortable it may be to let a vendor solve all your problems, giving up your freedom to choose and mix has consequences.


The Apple solution is now mostly closed as it is impossible to access an Apple music server from an non-Apple device. There is an open source server for the Apple audio protocols (the Firefly Media Server), but it is mostly unmaintained. If you are an all-Apple house, I am sure that you have already found satisfying solutions, but they will not be described further here. Otherwise, I would not recommend this approach as it is expensive and now closed (it seems that even the open source implementations of Airplay are dependant on a key which may be revoked in the future)..

Yet, see this comment for a very happy user with a home system based on the Apple protocols.

Google Chromecast

The Google Chromecast audio is an audio renderer device. It figures in this list because it can play files from a local music server (e.g. from an UPnP Media server), but it comes with a string (barbed wire) attached: it can’t work AT ALL without an Internet connection.

I bought one just to check this, because I found it unbelievable, but it’s true: if the local network is cut from the internet, the device will not play whatsoever, even local tracks. Think of it:

  • Internet connection down: no music.

  • Google servers down: no music.

  • Google decides that they don’t do music anymore: your device is a brick.

Under these conditions, it is my opinion that you may have bought the widget, but it still belongs to Google.

It is difficult to think of a reasonable technical justification for the device not to retain local function without an Internet connection, this is nasty, and I returned the purchase. However, if you are not sensitive to this issue (really: you should), there are nice aspects:

  • Cheap 35$, 39 Euros in France.

  • Analog and Optical outputs, and excellent audio quality (up to 24bits/96khz for you batmen).

  • Can play music stored on the remote (phone or tablet) in a pinch, but the normal way is to play streams directly from where they are stored (saves the phone battery).

  • Autonomous play queue (will continue playing even if the phone is off or doing something else)

  • Supported by many proprietary applications (Spotify, Qobuz, Tidal announced, etc.).

  • Synchronous play to multiple players (multiroom).

On the minus side:

  • It’s WIFI-only unless you buy an additional Ethernet adapter (15$)

  • It seems that gapless support is not flawless, and may depend on the application.

  • Codec support is not universal, but does include FLAC, which should make it good enough.

  • iOS clients (iphone or ipad as remote) are second-class citizens, and Linux ones semi-legal immigrants.

  • The Chromecast ecology is mostly closed, probably due to strict Google control, there is not a lot of adoption of the protocol to control other devices. So if you go Chromecast, you’ll have to stick a dongle to the back of your Linn receiver…​

  • No Internet No Music


The Squeeze family of devices were the pionneers, and I fancied buying a set for quite a long time, but there was always a bit missing to make the price right, and I never took the plunge. Logitech discontinued the hardware line, but the solution lives on thanks to open-source: the server part had always been an open-source package, and the client (renderer) part now has an open-source implementation too.

The wiki and forums are still hosted by Logitech.

There is a very lively Squeeze community. There are relatively few portable device clients (control points) available, but people seem to be happy with those that exist. It’s always possible to control everything through a web browser anyway.

The LMS/Squeezelite pair is a very nice solution. There is a tight integration between server and renderer, and most of the intelligence resides in the server (which also provides a WEB control interface). As a consequence, the system can implement a number of features with less effort than less integrated solutions:

  • multiroom synchronized audio from several devices, so that you could go from room to room while listening to the same music.

  • Numerous server plugins providing extended functions, for example to access Cloud services (Qobuz/Tidal/Spotify/etc.), or foreign protocols (Chromecast, UPnP).

  • A very lively and supportive community.

Apart from the fact that the LMS music browser is probably not quite as good as the best UPnP Content Directories, the main drawback is that there is about no support from hardware vendors: Logitech has discontinued the hardware players, and as far as I know, no hardware streamer currently supports LMS, they are all based on UPnP.

There is indeed a LMS-to-UPnP bridge plugin, but it is a complicated beast and probable source of trouble. It’s quite hard to bridge LMS and UPnP because of the very different architectures.

This means that you are confined to two possibilities for renderers:

  • Discontinued Logitech or Slim devices hardware, which you can still find on the second hand market. You can get a Squeezebox Touch for around 150 Euros, which is excellent value for a really great device.

  • "Build your own" solutions based on installing the client software somewhere (PC or Raspberry PI type unit). The 'build' part can be minimized by relying on a specialized software distribution (e.g. picoreplayer, max2play, volumio, runeaudio etc.), some of which can also supply close to pre-integrated hardware.

Because of the kind of software I develop, I am more of an UPnP guy, but after having played with a 2nd hand Squeezebox Touch for some time, I have to admit that it’s quite unbeatable in terms of what you get for the price and ease of use.


Roon is very close to LMS/Squeeze in its architecture. There is a server part named the Core which handles cataloging and streaming.

The renderers are implemented with a piece of Roon software running on a wide variety of devices: PCs, Macs, and a variety of mostly high-end streamers, but Roon also provides a free implementation for the Raspberry PI, which allows building cheap endpoints (no source though).

The Core sends audio to the endpoints through a proprietary protocol named RAAT, which supports multiroom synchronized playing. There are official (Roon-supported) gateways to Airplay and Logitech/Slim devices (LMS emulation). No sync for these. There are also a couple of gateways to UPnP devices, but they are not supported by Roon which officially hates UPnP.

The user interface is what makes Roon special: it can run on the same PC as the core, or as a remote on Android or iOS devices. It is a very rich presentation of the music catalog, with a lot of informative data coming from external services. The goal is to recreate the experience provided by the liner notes on the old LPs: information about the recording, the musicians, the composer etc. There is also a Radio mode which will create a custom program through your library, consistent with what you were last listening to.

This wealth of information does not come cheap, you will need a 120$/year subscription. Also the quirky interface can make it quite difficult to navigate to a specific album (you mostly have to rely on search).

Roon is very nice, and the user interface is special. The audio capabilities are excellent, but a bit less special than the Roon people, who have a tendancy to badmouth anything non-Roon, would let you believe. In single endpoint mode, Roon streaming is equivalent to UPnP (pull mode), and in multiroom mode, it works like Linn Songcast (one endpoint is master and working in pull mode, the others have to adapt their clocks).


One gets the feeling that the Music Player Daemon has been around forevever, but it’s actually a little younger than Slim/Squeeze devices, having been created in 2003.

This is a combined media server and renderer, with a seemingly endless list of controller clients. There are all kinds of MPD clients: curses-based terminal applications, iOS or Android app, local GUI programs, or WEB-based.

MPD can run on all kinds of computers, but the main attraction are the small ones which you can stick behind the stereo (à la chromecast, but all yours). More on MPD further down.


Last but not least comes the UPnP/DLNA family, and its OpenHome cousin. UPnP is a set of standard and open industry-defined protocols for networking home devices, among others multimedia ones. DLNA is a consortium-defined refinement of UPnP and is not open (but parts have "leaked"). Unlike the MPD protocol which has a unique implementation with the MPD software, UPnP is implemented independantly by many software packages and devices (most HiFi "streamers" are based on UPnP DLNA). More details further down.


UPnP has a very closely related variant named OpenHome ohMedia. Some of the best audio control points implement both UPnP and ohMedia. OpenHome renderers play from standard UPnP/DLNA media servers, but have a slightly different control protocol.

The nice thing with UPnP and OpenHome is that you can mix and match very high end equipment (e.g. Linn in the music room) and cheap devices, (e.g. Raspberry Pi in the kitchen), and control everything from the same application (mostly).

Enough with the suspense, UPnP+OpenHome is now my choice. More details further down.

Among the three approaches which I like to diverse degrees (Squeeze, MPD, UPnP), one nice aspect of UPnP-based solutions is that they cover wide ranges in two important axes:

  • You can buy a purely commercial system, with no need for tinkering, or you can go as far as as you want in the Do It Yourself direction (from simple approaches like an audio-oriented distribution on a Raspberry Pi to more customized solutions), and you can mix the two.

  • Independantly of the buy/build compromise, the price range is very wide: you could buy a complete system, NAS + renderer amp, for a few hundred Euros or a few dozen thousands, and you can build one from around 100 Euros (RPi renderer using your home PC as a media server).

Switching ?

Apart from solutions based on specific hardware (Sonos, Chromecast), the software implementing the different approaches (Squeeze/MPD/UPnP) can run on the same hardware (from ARM Single Board Computers to Linux or Windows PCs to Macs), so that switching from one to the other is mostly a matter of reinstalling a few software packages. Running several in parallel is also mostly possible.

The next sections will describe MPD, UPnP, and ohMedia in a little more detail, the last part will try to define some reasons for choosing one or the other (there is no obvious choice).


In its default form, the Music Player Daemon combines a music player and tags manager. It normally accesses the audio files through a file-level protocol (direct, SMB or NFS), both for playing and for creating its tags database. It can also accept HTTP or other network URLs for "foreign" audio files or streams to be played (e.g.: internet radios).

The daemon can run on most Unix/Linux systems and also Mac OS X and Windows. It can decode most audio formats, using external libraries.

The front side presents a network TCP/IP control protocol, for which a high number of clients (remote control applications) exist, graphical or not, on every possible OS and hardware platform.

MPD has a number of important characteristics:

  • The playlist belongs to the player. Several clients can access and manipulate it, but once they are done, the server will keep playing the defined track sequence all by itself. Any client can retrieve the current playlist at any time (see what is coming), and also manipulate it. This is nice when there are several users: each can take a look to see what’s playing, and possibly add/remove titles, mute if they need some quiet, etc.

  • Each player maintains a local tags database. Updating it needs checking all audio files and reading the tags for all files that changed. If there are many tracks, doing this multiple times (once for each player) is a source of additional load and possible issues. There are workarounds for this, they are listed in the practical section.

  • MPD servers announce themselves on the network using Zeroconf, but the clients are usually not too good at discovery, you will have to configure the servers manually, and switching servers on a controller (because you went from the study to the kitchen) is feasible but usually not very convenient.

  • MPD clients are not themselves able to play music: you won’t be able to use them for listening directly on the mobile device.


Software based on the UPnP Audio/Video protocols implements the same services defined above, but, compared to MPD, the separation is different:

  • The file server and tags database manager are usually combined inside a device called Media Server, inside which the tags management part is the Content Directory.

  • The audio/video player is named a Media Renderer.

  • The controller is named a Control Point

The Media Server can give access to the data using a variety of protocols (HTTP, RTP, …​), the methods for data transfers are not specific to UPnP. It will usually run on some kind of file server, which can also give access to the files using the common file sharing protocols (NFS, SMB).

One of the nice things with UPnP is that it is widely supported. Your recent connected TV is probably already an UPnP Media Renderer. If you have a network appliance for sharing your files at home, it probably includes a Media Server. There are also multiple software implementations of the different services, open-source or not, able to run on most kinds of hardware and OS.

There are major functional points on which the UPnP family differs from MPD:

  • The Content Directory is a central service (there may be several, but each manages its files), to be accessed by the Control Points for choosing music. The tags database computation is not duplicated (this is a good thing!).

  • Playlists belong to Control Points.

    • You use your handheld device to build a playlist from directory contents, and the device then instructs the renderer it is associated with to play the sequence of tracks.

    • This means that a Renderer can mostly be accessed by only one control point, else confusion is almost guaranteed (this is less nice than the MPD approach).

    • Also, if the Control Point goes to sleep, the sequence will stop after the current or the next track.

    • Conversely, you take the playlist with you: if you move and associate with another renderer (went from kitchen to study), your control point should be able to transfer the playing (not all implementations do it properly though, but some do, for example the Bubble UPnP Android app).

  • UPnP devices are usually very good at discovery, this is one of the main "raison d’être" of the protocols. Your Control Point should almost immediately show you all Media Servers and Media Renderers on the network (including usually, a local Renderer, to play on the mobile device itself as many UPnP control points also implement a renderer), and let you choose and switch very easily.

OpenHome ohMedia

OpenHome is probably supposed to be some kind of industry alliance, but, as far as I know it is exactly composed of Linn Devices, a British supplier of high end audio equipment.

OpenHome has published ohMedia, a set of standards for network audio, which have been implemented in a number of hardware and software products beyond those from Linn.

ohMedia is based on the UPnP base protocols, but it uses different services. The most important difference from the user point of view is that ohMedia has a Playlist service which manages the play queue much in the same way that MPD does, meaning that the music will go on playing even if the Control Point goes to sleep or is turned-off.

Some of the best UPnP control point software packages (e.g. Bubble UPnP, PlugPlayer) include support for both bare UPnP and ohMedia. In cases where a device supports both interfaces, they will default to ohMedia. Using several ohMedia control points on the same device is not a problem, but mixing UPnP A/V and ohMedia control points is sure to end in confusion because of the very different play queue management.

MPD / UPnP: comparison and choice

If you live alone in multiple rooms each with a music system, and want to be able to change places from time to time while keeping your current playlist, you want UPnP.

If you live with friends, and the network audio system is mainly used to control the stereo in the common room, you may prefer MPD.

My current preferences goes to ohMedia:

  • The best UPnP control points support it, and, because they have more users, they are generally better than the equivalent MPD clients.

  • The shared playlist is much more convenient to use in general (except for the moving from room to room situation).

In practise: a small list of implementation blends

Go practical: the following lists a few concrete options, with the actual software that you may install and a few useful links. All players cited can be installed on any Linux computer, including Raspberry PIs and similar appliances.

Pure MPD

Let’s bite the bullet: all MPD instances will have to update their own tags database. After all, what else do they have to do at night ?

Choose an MPD client, maybe MPDroid on Android.

Not all your MPD instances are going to run on PCs, and you may be interested by my document about installing MPD on a Raspberry PI. Update: this document now start with an advice that non-tinkerers can now just install a Linux distribution specialized for audio: Volumio, RuneAudio, Archphile or Moode, instead of setting up the different bits by hand…​

MPD with shared tags database

You are an MPD diehard, but you don’t like the idea of a duplicated tags db (I hate it, which is not very rational actually…​).

There are two semi-standard solution to have several MPD players share a tags database:

  • The MPD proxy database plugin lets a daemon use the DB from another one. In this situation you will run one MPD instance to manage the directory (maybe on the file server), and the others will share it.

  • The MPD UPnP Media Server plugin lets the daemon use an UPnP Media Server as tags database and audio data server. In this approach, MPD does not manage any data, it forwards the tags information from the UPnP Content Directory to its clients, and fetches the audio data from the UPnP Media Server.

Both of are enabled in the current production MPD (0.19). Availability in the standard package repositories will depend on the kind of system you are running though. I do maintain a few backported mpd packages here.

If you chose this approach, you will also be running an MPD client as user interface.

MPD with UPnP front-end

Several UPnP Media Renderers use MPD behind the scene to do the actual playing. This is the case for example for MediaPlayer (Java), and upmpdcli (C++). Both support UPnP and the OpenHome protocols.

This is an excellent approach, combining the great audio quality of MPD with a standard front-end (disclosure: I am the upmpdcli author).

You will need an UPnP Media Server and Control Point to run with this (see further).

Pure UPnP

There are myriads of commercial UPnP Media Renderers. Mostly all "connected" media devices run one, from small widgets to high-end audiophile components.

For completeness on small open devices (e.g.: RPi) gmrender-resurrect is an open-source Media Renderer which uses the gstreamer libraries for playing the audio. As far as I know, it only supports UPnP (not ohMedia). There are frequent reports of gaplessness issues with it.

You will need an UPnP Media Server and Control Point to run with this (see further).

UPnP Media Servers and Control Points

There are many UPnP Media Servers. Maybe one already runs on your NAS (the quality is not always great). The open-source minidlna is quite serviceable. MinimServer is excellent (really: the best of the free ones) but it is not open source (free as in beer though). There are also a number of very good commercial offerings: Asset UPnP, Twonky, Serviio, JRiver etc.

There are myriads of UPnP Control Points. I mostly tried those running on Android, and I found that BubbleUPnP is just better than the others — this is not an advertisement. I’ll list another app as soon as I find a good one, but I did try many with no luck at all. Someone mentionned HiFi Cast in a comment.

PlugPlayer is also supposed to be good, but I did not initially have much luck with it (I think it’s primarily an iOS app). It seems that recent Android versions are improved.

Linn has a nice application named Kazoo to control an OpenHome renderer (this replaces Kinsky). I only tested the Windows version, but there are also Mac, Android and iOS ones. However, Kinsky used to work quite badly with AVTransport (non-OpenHome) renderers, and Kazoo does not seem to work at all with them. Also Kazoo tolerance of non-Linn renderers is a moving feature (works in a release, then not, maybe back again later).

Under Linux, there is not a plethora of Control Point applications, so I’ll plug mine here, upplay. Upplay now also runs under Windows, but you may find it a bit on the barebones side.

For Windows, there are quite a few commercial offerings of applications with a UPnP Control Point feature among other functions (JRiver for example).

comments powered by Disqus