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 PIs architecture and hardware can NOT be considered top notch (other SBC do (much) better at similar price levels), a PI can very well serve the purpose - to act as a rather serious audio transport. 
Not as an off-the-shelve installation, no, it requires some tweaking to get serious quality audio from that device. 

What makes a device like the RPI a success story is its wide market presence,
great and innovative SW (manufacturer+community) support and OEMs flooding the market with all kind of (quality) gadgets.
Many other SBC companies failed to succeed (beyond becoming a niche product), because they were not able 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 to go for a PI.





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)
* better no USB DAC (rather poor USB implementation) 
* however it'll work with USB reclocker/regenerator/repower/filter gadgets though)
* as I2S audio source with at least an I2S reclocker (e.g. Allo Kali) attached


With this series of articles I'd like to give a little guidance to get you going. I'll try to show how to get serious audio quality from that device.




Hardware

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!

* 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 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 option 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 - 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 ...


Software

First you need to find the right operating system (OS). Meanwhile you'll find numerous
OS images with special focus on audio. These you just copy 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 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. 

Beside that the OS of choice must come with most up2date SW - kernel and packages!

To make a long story short:

piCorePlayer (pCP) is doing quite well on all accounts. pCP also now offers an audio optimized realtime kernel and several special audio card drivers. (I'm having quite a close contact to the pCP team)

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.


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 (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 main audio engine. 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.
However. 
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 is based on Unix/Linux systems!!! 


Let's continue with piCorePlayer.

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.

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

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
Enjoy.

No comments:

Post a Comment