A Logitech Media Server / LMS Infrastructure (Update)
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 and this is an update to the original article.
Logitech Media Server is a piece of software, and it’s well described here: https://en.wikipedia.org/wiki/Logitech_Media_Server
The highlights:
- 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, and manages its stock and access, and distributes them 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 software on a general purpose system e.g. your pc, your Mac, your xbox, etc, or finally you can build a “hardware rendering device” from scracth, which is indeed my case and the good news is that it is way less complicated than it seems.
The physical system acting as LMS server may also have a Renderer inside, to “manage files, and play them out” from the same machine. Even in such case though that machine will keep being able to stream audio to other external Renderers.
While streaming audio to Renders, LMS can also manage keeping them “in sync”, resulting in simultaneous music playout in different rooms, for example.
So summarising:
- LMS is “the server”, the manager of the whole system. It cllects and indexes music files, makes them browsable, and sends (“streams”) them to companion devices called “Renderers”.
- The Renderers are the devices which get digital music data streams from LMS and push them into a locally connected DAC>AMP>Speaker/HP/IEM stack.
How I deployed 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 has been organised, 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. By comparison, an entry level X386/X64 NUC consumes at least 20 times more.
Retail-market electricity costs in Italy are right now (June 2022) around € 0,48 per KWh including taxes and everything (up from 0,21 last year). Which means that choosing an SBC device as a host platform for a decently performing LMS server impacts on my household total electrical bill for € 2,4 / year, instead of € 50 or so, always per year.
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 one of my PCs, or Laptops, or wifi 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.
Renderers
My first Renderer was 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 them 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 standalone Banana-LMS device acting as a server, and I could have elected one or my Renderers to the role of Renderer and 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. At that point I can browse and choose a song from LMS’s visual index, a Renderer to send it to, and click PLAY.
I have a total of 3 RPi-base Renderers active right now.
Allo
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 a DAC to write home about in terms of reconstruction fidelity etc – hell, it also costs like $30…! – but it fares well nonetheless, 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 incoporates a master clock, which allows it to avoid the main shortcoming of lowend RaspberryPi models.
So it’s not a TOTL device, but no shit either… at all ! 🙂
Such mini-network-DAC box is subsequently connected to an Allo Volt+ amp box, giving juice to a pair of Roth Audio OLIRA1 bookshelvers. 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.
Groovy
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 model from which on the internal USB bus has been redesigned, and 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”. This is why 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. At the same time, 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.
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.
Fun
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 a not particularly pretentious yet more than decent Allo 5V SPMS. 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.
An AudioQuest Jitterbug FMJ is then connected in series as a further signal conditioner. An Uptone USPCB adapter plugged into the Jitterbug is how my second Groove finally gets on.
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. You do that by installing a windows app called SqueezeLite-X, 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 cutting the problem at the source instead of fixing it later is a smarter option, when available! So I quit employing a noisy platform like a laptop in the first place, and now excluisively adopt 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 on higher rank systems like Roon, but still quite pleasing nonetheless, with the non-secondary side-benefit of being… 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 actually 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 NAS, and let LMS access them too.
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: Logitech Media Server can be the heart and the brain of an entire domestic audio infrastructure.
What it ultimately offered 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)
All this at an extremely low cost profile: LMS and its various Rendering companion sw packages are free of licenses, they can run on ARM-based hardware which is both inexpensive to buy (compared to an X86/X64 class alternative) and to electrically power up.
LMS served me well as my main audio infrastructure until a few months ago, when I switched over to Roon. I’ll write another piece on that… soon(tm).
I’m currently running LMS+pCP on an RPi4 (local music is on a USB SSD drive), directly connected to a USB DAC in my main system. I have a few additional renderers for less crucial setups.
Do you see any disadvantage to run LMS+pCP on the same device, vs using a dedicated LMS server?
The more a machine “does” at the same time, the more mess it creates, the more perturbation there will be in signals timing etc.
This being true, the right question is of course “will this be perceivable”? And the answer depends on the level of quality you expect and on the level of the rest of your audio gear. If for example the RPI4 is connected to a quite entry level USB DAC, and/or with no particular attention to dejittering that connection etc etc, then I can assure you that having your RPI do 1 or 2 things at the same time will never make any difference. On much more sophisticated setups it will be the other way around.
Have been a huge fan of Squeezebox since it first arrived on the scene. These days I run LMS in a docker image on my NAS.
Is there any reason you wouldn’t consider using the Logitech renderers e.g. the duet? They are often found at bargain prices on eBay and have digital outputs ready for a decent DAC.
You should test the material skin for lms. The web Frontend is fantastic!
https://github.com/CDrummond/lms-material