Wednesday, January 10, 2018

Raspberry Pi - The Audio Engine - Part 1 - Introduction

Since 2013 I'm using and working with the Raspberry Pi as audio streamer. 
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 SBC do (much) better at similar price levels - what makes the RPI a success story is its full package. 
Beside its mediocre HW, the RPi  offers (long term) quality and innovative SW support (manufacturer + OEM + community) and a huge community backing the device.   

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 - proper and 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.

Once you have achieved a market position like the RPI, you'll see more and more OEMs flooding the market with all kind of partially high quality and uselful gadgets for the RPI. That'll make live for the competition even harder.

For us audio folks the HW capabilities of a computer play quite a big role. And that's the weak spot of PI.

However. A PI 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. 

The challenge

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, no onboard WLAN/BT)
* headless (no screen attached)

* as I2S audio source with at least an I2S reclocker (e.g. Allo Kali) attached
* better not attach a USB DAC (rather poor RPI USB implementation) 
* however it can 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 PI3
   I use the PI3. 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)

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!

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. 

HW alone won't make a great transport though!!  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 "" . 
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 try them all. There's absolutely no reason arguing about which one is better.
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 comes with squeezelite support. I don't want 
a local server and data storage on the Pi, I'll use a network storage and network server. 
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 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 realtime kernel and several special audio card drivers. I'm having quite a close contact to the pCP team - a lot of stuff from this blog you'll find implemented into pCP over time.

Moode (I used to contribute quite some stuff 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.

piCorePlayer - makes a (almost) perfect OS, as base for a single purpose Audio streaming solution.

piCorePlayer (pCP)

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 PI3 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. 
Just to mention it. The official squeezelite maintainer is part of the team. Even the LMS maintainer is meanwhile part of the team.  All what's needed to get going. 

pCP also offers LogitechMediaServer (LMS) as optional package for the RPI. 
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.

Let's start shaping up your Audio streaming engine step by step:

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.

NOTE: Make sure you download and install the "Audio Optimized 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

No comments:

Post a Comment