I'm also contributing this or that to certain community projects.
Why Raspberry PI?
The Raspberry PI family is by far the most successful single-board-computer (SBC) out there.
Even though the RPI architecture and hardware can NOT be considered top notch - other SBCs do (much) better at similar price levels - what makes the RPI a success story is the full package. You simply can't look at such a device only from a HW perspective.
SW is key. HW and SW makes the package. Without quality SW HW specs mean nothing.
The whole RPi family comes with excellent SW support. And that SW support achieves highest quality standards. Beside that you look at long term SW support. The first generation PIs are still supported.
And that reliability and quality factor hooks up OEMs and people. A huge community is backing and supporting the RPI family because they know efforts are not wasted.
Many other SBC companies failed to succeed (beyond becoming a niche product), because they were not able to comply to these factors - even providing a much better HW wouldn't help. Without being able to address the key area - solid long-term SW support - these devices are pretty much worth nothing.
Providing, evolving and maintaining quality SW is a continuous process over a long period in time. That's what many manufactures underestimate! And that's why they usually fail.
And that's the main reason why people and OEMs stick to a PI.
However. A RPI can IMO very well serve the purpose - to act as a rather serious audio transport.
Not as an off-the-shelve installation though, no, it requires some specific setup considerations and a bit of tweaking to get serious quality audio from that device.
Taking a rather mediocre device (HW) like the RPI and make it a high quality audio transport.
The PI has its limitations.
The IMO best way of running it is
* as network streamer (no HDDs attached)
* headless (no screen attached)
* as I2S audio source with at least an I2S reclocker (e.g. Allo Kali) attached
* or audio HATs that slave the RPI I2S (achieving femto seconds jitter lecels!)
* better not attach a USB DAC (rather poor RPI USB implementation)* however USB dacs will work by using e.g. USB reclocker/regenerator/repower/filter devices
With this series of articles I'd like to give a little guidance to get you going.
I'll try to show how I managed to get serious audio quality from that device.
The hardware I'm currently using is:
* Raspberry PI3B+
I use the PI3B+. It gives me maximum flexibility and the best HW specs of the PI family.
* Allo Kali (I2S reclocker)
I2S quality delivered by the RPI is rather poor. The I2S reclocker is the ticket into quality
audio from RPI. With such a reclocker in place you'll achieve quality levels as known from
highest quality USB-I2S interfaces (which are also part of most commercial USB-DACs)!
* Allo Piano2.1 DAC (dual-mono mode)
Kali+Piano2.1 in dual-mono mode can beat the Allo Boss. IMO It's worth trying!
(I tried several other (DIY-) audio HATs and also (high quality) USB DACs)
Note: I didn't jump on the rather promising Allo Katana train yet.The project still (1/2019) seems suffering some teething issues.
As power supplies I use
* 2x iFi iPower 5V (1 for the RPI and 1 for the Kali + DAC)
(I also added some buffer capacitors to the power supply rails)
(I did try high quality "linear" supplies as well. Just to mention it!)Further I'm running a special HW setup for the network as described in my related articles.
If you're willing to walk the extra mile, don't miss that exercise! However. Just recentlym, with the introduction of the 3B+ I switched to onboard WLAN I wrote an article about that too. That approach IMO can save some effort and investments.
All this IMO makes a very nice audio streamer base. Of course there are numerous other options out there.
Above setup is the result of several projects I ran (usually in public on DIY-Audio) over the years.
I did also run high class USB DACs and PCs in the past - just to mention where I'm coming from.
As mentioned, HW alone won't make a great transport!! It'll be a well chosen combination of HW and ...
First you need to find the right operating system (OS). Meanwhile you'll find numerous
OS images with special focus on audio. These images you just write to SD card and you'll - almost - be set.
There are several feasible audio OS options for the RPI:
* Archphile (Arch Linux, MPD)
* DietPi (Debian, MPD, squeezelite)
* Moode (Debian, MPD, squeezelite)* PiCorePlayer (TinyCore, squeezelite)
* Rune (Arch Linux, MPD)
* Volumio (Debian, MPD)* and more
The differences between all of them are not earth shattering. Don't let you fool by marketing terms like "...phile..." or "...diet..." .
Do I have to save a couple of hundreds MBs of storage space - e.g. the key selling point of Diet-Pi, if I can't buy SD cards below 16GB anymore?
The maker of Arch"phile" tells us that he can't hear any differences no matter what "tweaks" he's building into his OS!?!?
Bottom line. You can easily try them all. There's absolutely no reason arguing about which one is better. (Several of them have taken in some of my tuning suggestions btw)
All the folks behind these packages do a great job in spending very long hours free of charge to build these packages. A real pity that there's so much redundancy out there!
My OS of choice would be the one that offers squeezelite support and runs as a lean headless streaming client.
I don't want to run local server duties, data storage or DSP work on the Pi. The PI runs out of steam very quickly. And no. I don't need a screen either - been there done done that.
I'll use a separate network server (NUC) that'll also cover the storage part.
This will keep the streamer as lean as it possibly can be.
As mentioned before, there are limitations associated to the RPI. Using it as bulky server
I do not consider a good idea.
A key decision factor should then be to go for a well maintained and up2date SW package.
To make a long story short:
piCorePlayer (pCP) is doing quite well on all accounts. pCP also offers an audio optimized version with realtime kernel and several special audio card drivers.
I'm in contact with the pCP team here and then. The team has several committed and capable folks onboard. And that includes the official LMS and squeezelite maintainers. Beside that they usually have an open ear for this or that "tuning" proposal.
Moode (I used to contribute quite some stuff (tunings and kernel) to Moode), Volumio and DietPi are based on Debian/Raspbian. Debian is NOT known for providing bleeding edge SW. That alone IMO is a major disadvantage.
Rune and Archphile are doing better on that account by using ArchLinuxArm as base. ArchLinuxArm is a rolling release. Basically you get the latest bleeding edge SW with every update. There's no need for major upgrades. And IMO Arch is as stable as Debian - you might hear people arguing otherwise.
Logitechmediaserver plus squeezelite IMO is by a large margin the best streaming solution out there.
It is flexible, it is opensource, it is highest quality, it is widely used, it is actively supported and it is free. Not to forget, there are plenty of quality apps on iOS and Android available as remotes.
I'm neither a big fan of MPD based systems (Volumio, Rune, Moode,...), even worse UPNP based systems, nor some other weird Windows (e.g. JRiver) originated solutions.
And Roon as a quite expensive commercial solution wouldn't give me any value add.
piCorePlayer - makes a (almost) perfect OS, as base for a single purpose Audio streaming solution.
It's basically a single purpose OS - an audio streaming OS.
pCP is a very, very slim OS. It requires less then 100MB.
The underlying OS (TinyCore) is a real "diet" OS.
It's greatest features:
pCP fully resides in RAM while up'n running.
There'll be pretty much no SD-card interaction during operation!
And still, on a PI3B+ we've got plenty of RAM left for our streaming task.
pCPs base OS (TinyCore), makes it difficult to tweak though. However.
The pCP folks offer some tools to do some tweaking. I'll come back on that later.
pCP offers squeezelite as the main audio engine.
Since the official squeezelite maintainer is part of the team, you can count on support.
Since the official squeezelite maintainer is part of the team, you can count on support.
You just have to enable it. And it'll work.
With LMS onboard things get tricky. LMS adds quite some extra load and noise. The lag on the remote apps is pretty annoying.
A rescan of the database with several thousands tracks takes ages. If you then want to support multiple clients from that server, things get funny.
If you look for a serious and powerful server performance, you better use your/a PC as LMS server.
I'm using a Broadwell i5 NUC as Linux server. I also use that very same NUC as day2day desktop machine - running the latest Ubuntu.
I would not recommend a NAS as server. Usually these are quite inflexible.
Running Windows and OSX servers would never be my first choice either.
There's a reason why pretty much the entire server/cloud world and that includes Microsoft is based on Unix/Linux systems!!!
Let's continue with piCorePlayer.
Are there any CONs?
The one thing that comes to mind is the user interface. It's kind of clunky, and can get
partially annoying (numerous "save" actions confirmations and "UI refreshes").
For me it is a "use-it-once-and-then-forget-about-it" interaction though. That UI does
the job and that's what actually matters. I wouldn't use it on a day-by-day basis. It's a simple work horse.
Let's get the job done.
I split the whole exercise of setting up your environment in several parts.
I'll skip the basic SD-card image installation procedure. Downloading and writing an SD-image to an SD card should be a known to most readers. There are also numerous guides out there how to do it. Here's pCP guideline.
NOTE: Make sure you download and install the "Audio Optimized/ rt-kernel version" of piCorePlayer.
Part 2: piCorePlayer settings
Part 3: squeezelite and DAC settings
Part 4: pcP Advanced Tuning Measures
Part 5: Building a tailored squeezelite binary
Part 6: DSD - DOP and native
Part 7: Realtime kernel
Part 8: Network Dongle
Part 9: Hub Control