A bit more than a year ago I published a piece describing features and benefits of my home LMS (Logitech Media Server) infrastructure. Over time my setup has evolved a bit and this is an update to the original article.
Logitech Media Server is a piece of software and it well described here: https://en.wikipedia.org/wiki/Logitech_Media_Server
- It gets music files or streams from a plethora of diverse origins (files on local storage, files from private or public cloud storage, streams from other private streaming platforms eg another LMS or from public services eg Spotify, Tidal, Qobuz…), transcodes formats if need be, and streams/sends the songs towards compatible “renderers”, i.e. music players which in their turn feed the actual audio hw (DAC -> AMP -> Transducer)
- It’s available for Windows, Mac and of course Linux, including a few specialised Linux distributions
- It therefore runs on “usual” X386/64 hw, Apple hw, and – what matters most – on a huge array of low cost and especially low power consuming SBCs (Single Board Computers)
- Considering today’s available hw performance level, its system (CPU/RAM etc) requirements for an even fancy home setup are unbelievably low
- It’s free (GNU)
LMS does not “play music”, it just collects music, manages its stock, access and distribution to the actual music players (the “renderes”).
As a “renderer” you can use either a preconfigured hardware device (e.g. a Chromecast, a Squeezebox, etc, which can be reached via various channels like wired ethernet, wifi ethernet, BT, AirpPlay and protocols like DLNA etc), or you can install a compatible receiver sw on a general purpose system (e.g. your pc, your mac, your xbox, etc), or finally build a “hardware rendering device” from scracth, which is indeed my case and the good news is that doing that is way less complicated than it seems.
The system acting as LMS server may also have a Renderer inside itself. In that case it will at the same time still be able to stream audio to other external Renderers.
While streaming audio to multiple renders LMS can also manage to keep them in sync, obtaining simultaneous music distribution in more rooms for example.
- LMS is the “server” managing the whole system. It collects and indexes the music, makes it browsable, etc.
- Renderers are the outputs, i.e. the devices which send digital music data to a DAC>AMP>Speaker/HP/IEM
How I use it
No I won’t write a full book on the infinite ways to deploy an LMS infrastructure. I’ll just describe how my own infrastructure is organised now, for you to take inspiration 🙂
My LMS is running on an SBC-class computer.
In my specific case we’re talking about a BananaPi M2+ (recently upgraded from a NanoPi NEO2 , which is now dedicated to other tasks) but it could easily be “any” RaspberryPi, or dozens of similar alternatives.
I’ve chosen an ARM-based SBC vs a X386/X64 NUC due to its dramatically lower power requirements.
My BananaPi drains like 2W while working, less than 0.5W while idle (easily 90% of its time), which means 5 KWh in a year, i.e. a whopping 1.5€ of total annual cost in the electrical bill.
By comparison, an entry level X386/X64 NUC consumes at least 20 times more.
My Banana-LMS server is wired-connected to my main home network switch.
Another SBC-class server is acting as a general file server for my home needs, that’s where my digital music files are deposited, and my Banana-LMS accesses them via NFS. In a simpler setup, I could plug a USB drive right onto Banana-LMS of course.
Once installed, the LMS server publishes an HTML interface. Which means that from any of my PCs or wifi enabled devices (phones, tablets, daps…) I can access it as long as I can browse onto its address.
LMS creates an index of all music files on the storage, much like any “media manager” application does (including those inside DAPs).
Let’s now suspend the LMS description for a sec, and pass on to the Renderers.
My first Renderer was, and still is – guess what – a RaspberryPi Zero W.
As you read above, a Renderer is a device which takes the digital music data from the LMS server and sends that to the actual DAC. To do so, some sort of “music player” application is required.
My choice on that is PiCorePlayer which I like as it offers two great features at the same time: it’s super-easy to install, and it sounds wonderfully well.
PiCorePlayer on Linux platform is distributed complete with a bare-bones Linux distribution, ready to work and do its job – and its job only – at the best of the hosting hardware ability. The maximally stripped-down, highly-optimised nature of PiCorePlayer’s underlying Linux distro is crucial to its performance as a low-noise music player.
It’s good to note that PiCorePlayer also optionally carries LMS built in. That means that in an even simpler situation I could have avoided keeping a separate device acting as a server (Banana-LMS in my case), and I could have elected one or my Renderers to act both as a Renderer and a Server for itself, and for all others.
Once at least one Renderer (the PiCorePlayer) is installed and running, I can go back onto LMS’s webpage – called from a phone, while sitting on the sofa – and I’ll see a Renderer available in my network. I can now browse and choose a song from LMS’s visual index, choose the Renderer to send it to, and click PLAY.
Developing on such concept, I now have a total of 3 RPi-base Renderers active at home.
My first Renderer is the aforementioned RaspberryPi ZeroW, and it’s called Allo, at it hosts an Allo MiniBoss I2C DAC card.
I bought the MiniBOSS some sweet time ago to start getting my hands dirty with dacs.
MiniBOSS is not the top technical DAC you may encounter in terms of reconstruction fidelity etc – hell, it also costs like $38…! – but it fares well nonetheless on the musical side, it’s got an I2S arcitecture (i.e. – it connects directly to the digital stream source, without passing via an intermedium e.g. USB or S/PDIF), AND it incorporates a master clock. Both such latest features allow it to avoid the main shortcomings of lowend RaspberryPi models: crammed-down USB implementation and a quite finnicky system clock.
So it’s not a TOTL device, but no shit either at all, and it converts a super lowcost platform like a RaspberryPi Zero into an incredible quality network-attached DAC ! 🙂
Both the Allo Renderer and the Allo Volt+ are powered by Allo power supplies, entry level tiers (respectively their 5V SMPS on the Renderer and the Allo 19V SMPS on the Volt+).
Depending on my seasonal feelings, the Allo renderer and its downstream line is either installed in a sitting corner in my livingroom, or takes some place on my desk and around it as a nearfield setup, for some non-overpretentious-quality audio output.
My second PiCorePlayer-based Renderer is a Raspberry model 3B+, which is sitting on my desk, next to my PC.
Why a 3B+? Well surely it’s more performant compared to a Zero but such headroom is not really so vital when the board is fully dedicated to a mere PiCorePlayer.
Rather, 3B+ is the first Respberry tier model with a redesigned USB bus, where jitter issues have been dramatically reduced or fully fixed.
Although a 3B+ is OOTB way less digital-noisy than a PC it still welcomes an at least decent audio-grade Power Supply, and some further USB clocking “correction”. To such aim I paired it with my iFi Nano iUSB 3.0 PS and USB conditioner. The Nano iUSB’s clean-power output is used as this RPi’s main PS. Nano iUSB 3.0 is connected to one of RPi 3B+’s USB ports, and a USB DAC is ultimately connected to Nano iUSB 3.0’s digital USB-out.
To this Renderer one of my Groove units is normally plugged in, and it’s the resource I tap onto when I want to enjoy some specific drivers directly paired to the Groove. Hence the name “Groovy” 🙂
Indeed, Groovy is also what I typically use as a realiable, reasonably-clean USB host to audition other USB-input DACs or DAC/AMPs that I happen to receive from time to time.
The third PiCorePlayer Renderer is named “Fun”, and it’s based on a more recent RaspberryPi model 4B.
This is the support device for my “main desktop stack” for headphones at the moment, ending into my Burson Fun headphone amp – hence of course the name given to the PCP device.
As a Power Supply for the RPi 4B I adopted another Allo 5V SPMS. It’s an entry level model but the PS powering the RPi is not required to do miracles in this case actually, as on the USB output side I connected an iFi iDefender to block outgoing power-related noise, and an Allo Nirvana SMPS is side-plugged onto that, to supply its much cleaner power to the downstream digital devices.
PiCorePlayer takes care of keeping the Groove stuck at 55% output volume level – as this corresponds to 2V FS which is the cap my Burson Fun headphone amp likes (well… requires indeed) in terms of input voltage to avoid clipping.
The entire stack’s effectively active volume control is the one on the Burson Fun, of course.
Cutting the laptop out
Until some time ago I used to have a 4th Rendering point represented by my Windows Laptop itself. That was done by installing the SqueezeLite-X on the PC, which takes care of talking to the backend LMS server – much like a PiCorePlayer does.
I used to, as I said, then more recently I quit using my laptop as a host for musical playing for good.
Long story short: the level of perturbance generated on a multipurpose, multimedia, gaming-level laptop like mine is significant. While a filter like the iFi Nano iUSB 3.0 undoubtedly helps reducing much of that, it’s nevertheless quite evident that there’s no noise like no noise in the first place!
So I quit employing a noisy platform in the first place, and now excluisively adopted less-noisy-to-begin-with ones for my musical pleasures.
More about LMS
So LMS allows me to browse my local digital music collection, and “play out” my preferred tracks on any of my connected Renderers.
I can reach that and browse through it via a normal web browser, or a nice number of supporting apps – either fully dedicated ones (e.g. OrangeSqueeze or others, available on Google Play) or multi purpose ones (e.g. UAPP, Neutron, HiBy Music, or any other app featuring DLNA-Controller capabilities)
If music tracks are decently tagged LMS also does some nice job in terms of music collection presentation. You can also have it acquire and cache album art, album and artist info, and even lyrics from various online resources.
If you access it via a browser you can choose the GUI “skin” you prefer, or customise your own if you are skilled enough. The UI is not remotely as phantasmagorical as Roon’s, but still quite pleasing nonetheless, with the non-secondary side-benefit of being… totally free.
And there’s more: a host of additional features can be activated / removed in forms of plugins. Some examples:
Format conversion. LMS can convert to/from countless digital formats on the fly, i.e., while sending the file to the Renderer (and the DAC attached to it). So for example it can convert (e.g.) a DSF 128 track into a 24 bit / 176.4KHz PCM FLAC file while sending it to an endpoint which won’t natively be able to decode the DSF itself. Big caveat: this does require quite some muscle! My BananaPi-LMS does not have enough for that, for example. So for all DSD-level tracks I have, I took care of creating their relevant PCM (FLAC) version, and stored it as an alternative version of the same album on my LMS.
Tidal, Spotify, Qobuz integration. Adding account credentials to LMS, it will connect to those services and make them available for browsing from within its GUI, and for reforwarding to the Renderers – just like it happens for any local-resident digital track.
UPnP / DLNA integration. I partially already covered this above. Any DLNA-capable mobile device (phone, tablet, dap, etc) can home interact with LMS. If the device only has DLNA-client support, you can only use it as a sort of Renderer – i.e., you need another device to browse LMS and push music from LMS into the DLNA-client device. If the device has full DLNA-controller support, instead, then it will be able to browse LMS in full authonomy, and call tracks to play onto itself. This – of course – can happen from “inside home”, and from “outside home”, provided you made your LMS accessible from the outside of course, and that your outgoing internet bandwidth is at least decent.
Airplay integration, Webradio integration, etc etc etc
Summary and conclusions
So, summarising: LMS is the heart and the brain of my domestic audio infrastructure.
What it ultimately offers me is:
- A centralised visual database of all my local digital audio material
- Some nice integration with extra artist / track information
- Access from within home, and from outside (via VPN).
- An “easy” way to keep digital audio transport off from general purpose computer hardware and OS (higher audio quality)
- A very conservatively upgradeable global system: whenever I want to improve some quality I “just” have to swap a component, like a better board, or a better PS, or better cables – without having to redesign / repurchase much or even “anything” else.
…and, a lot of fun diy-ing it all 🙂