the base

(Latest update/review: Feb-02-2022)

Objective

The goal with the base article of The Audio Streaming Series is to work out how to select and build a

• no frills
• low latency
• high efficiency
• smooth running
• flexible
• and easy to manage

operating system base that's tailored to the RPi and matches our audiophile directions:

The Operating System.

Getting the foundation right of actually any such project must be considered a key success factor.
the base article hopefully will support you to get that foundation right for your top quality audio streaming solution.

First we'll look for an operating system (OS) that qualifies for the job.

Pretty much all operating systems, and that includes all those "...phile" systems, you look at come as rather generic solutions. Basically standard OSes nicely wrapped and fancy marketed. Most of the efforts are usually spent on the user interfaces, which have nothing to do with the actual streaming or processing jobs. Most OSes you'll find are pretty bloated to please and address a wide customer base. Many, for most people useless, features and functions are being developed and maintained with huge efforts. Many of this stuff idles or keeps poking around in the background, eating up precious resources on your streamer or causes this or that disturbance on your audio data streams.


Let's  get a step ahead of the bunch. ;)

OS selection

On RPi based systems the OS of choice is based on Linux. Period. A linux system consists of two main parts (key elements). The

• kernel space
• user space

All Linux systems, Raspberry Pi OS, Arch Linux, Gentoo, PiCore, you name it,  follow that structure.
Under the hood pretty much all Linux systems are very similar.

One huge difference on a RPi OS compared to other non-RPi OSes is the RPi kernel.

The RPi foundation puts enormous efforts into the kernel space. They maintain their
own foundation kernel. That's done to enable a highly efficient HW (RPi) specific kernel and a huge number of 3rd party devices. Beside that it allows for very short-term corrections and improvements, that would never make it into the Linus Torvalds maintained so called mainline kernel.
That RPI tailored kernel is IMO one of the key success factors of the entire RPi business model. 

When it comes to choosing a high performance operating system it is key to go for a system with

• bleeding edge kernel and firmware (kernel space)
• bleeding edge SW (userspace)
• high reliability and stability
• high flexibility
• quality support
• long term support
• high manageability (even for non-nerds)

The to me currently leading OS that matches above list to quite a large extent is piCorePlayer (pCP). It's
been my top pick for a while. Of course pCP is not getting 5 stars on each of above bullets. 

E.g. Flexibility is one of the key weaknesses of that TinyCore OS based pCP system. TinyCore makes it a nightmare for a designer or maintainer to get something done quickly. The pCP maintainers though try to build-in the flexibility that'd be demanded by the advanced audio user into the user interface.
pCP also comes with several tweaks/system optimizations that serve specifically its audio streaming purpose already built-in. Therefore pCP gets a OS-of-Choice recommendation.

Just to mention it.

I personally use my own customized OS based on Raspberry Pi OS 64.  Why? Because I can do and do everything on my own. And RPi OS is the development platform supplied by the RPi foundation.
When it comes to best HW support there's no way around RPi OS. However. The Debian OS is used as base for RPi OS. That leads partially to having quite dated software on on the disk. Anyhow. The mission critical software I add and compile myself. 

Let's get started.

Prerequisites

Before we start the journey we have to make sure to comply to below checklist

• we use preferably the RPi 4B (with slight adaptations this or that setting can also be applied to other RPI models)
• latest 64bit piCorePlayer is installed on uSD-card
• you run a highest quality "fresh" uSD-card ( Samsung EVO Select 32GB SDHC will do)
  running a SSD on USB could be a much better choice though.
• an audio interface, I2S HAT or USB DAC, is attached
• high quality, rock solid, low noise power supplies are attached, preferably separate supplies for audio interface, RPi and optional SSD are being used ( how? - see iFi iDefender )
• you have a high quality passive cooling case that keeps the RPi below 50°C.
• an LMS server is up'n running (can also be a RPi4 based server, with SSD attached)

I further assume (recommend) that the whole RPi setup

• runs headless - with no display attached
• and no keyboard attached
• is not using infrared controls
• or Airplay
• or Bluetooth

When it comes to networking you need to decide on either of following options:

• LAN - wired networking - which requires a cable connected to the router
• WLAN - wireless networking - which requires a high quality WLAN environment

Currently my favorite mode is ethernet (wired) LAN. Those of you who'd like (or have to) to run WiFi have to read my network related article the net to get the WiFi setup properly in place.

Setup

With the

• pCP-loaded SD-card inserted,
• the RPI network cable connected to the router or HUB and
• the RPI powered up

you should be able to access the pCP Main Window from any WEB browser in your home network.

pCP Main Window

Let's start to have a look at the pCP Main Window .

 




Wait a minute! How do we actually get to the pCP Main Window ???

You "just" enter the IP network address whatever it is - 192.xxx.xxx.x - of your RPI into the web browsers address line and press return.
The pCP Main Window will show up after a few seconds.

Got you. How do we find out that IP address?
Your best bet is a remote login to your router via web browser. Once you're inside your router, look for a menu that shows connected clients in the network.
Look for your RPi. Write down it's IP address.
While you're at it also write down your server IP address. Keep that note somewhere.
One last thing you should do while you're still in the router menu. Configure "reserve IP address" for your RPi and for the server.
Pretty much every router out there should offer this functionality. It might be called slightly different from router to router.
Doing it this way has a huge advantage. You'll always get the same IP address assigned by the router to your RPi and
to your server and you don't have to fiddle around with static IP addresses!

Once this is done you can connect to pCP by entering the RPi IP into the browser.
As soon as pCP pops up, bookmark that link for the next access!
Put that bookmark right beside your LMS bookmark and your router bookmarks. ;)


Back to the pCP Main Window.




At the bottom of the main window, you see "Beta" option to be able to access all pCP options. That's what we go for.  Beta simply implies that the pCP folks haven't tested any potential scenarios that can be selected by choosing  all kind of variations. I never had any issues wit that.

Main Page

We continue from here with our initial setup on the "Main Page"

 

Resize FS

The first thing we should do, we should increase the filesystem.




I'd suggest to increase the filesystem to 200MB. That should be more than sufficient for all actions that'll come later on.

Update

Next we run a what the pCP teams calls a patch-update and a minor-update. Basically these are minor updates for all installed applications and OS.

 

Squeezelite Update

That can be accomplished by hitting the Full Update button on the Main Page. Just do it.

Some General Stuff

There is a small number of functions on the Main page that we gonna use once in a while. You find them here:

• Reboot - reboots the system
• Shutdown - shutdown the system - you still need to do the powerdown manually!
• Extensions - we might need to load some extra applications later on
• Updates

We're done with that part.

Squeezelite Settings

Squeezelite settings are covered separately in a separate article of this series.
We can skip that for now.

Wifi Settings

Let's have a look at the Wifi settings. We need to turn some stuff off.  

 


...and off they go 

• RPI Built-in Wifi and
• RPI Built-in Bluetooth

SAVE IT

Tweaks

Next comes the pCP System Tweaks section. It's getting more serious by the click.

• turn off piCorePlayer Tabs - SAVE IT
• turn off LMS Controls Toolbar - SAVE IT
• HDMI power we turn off - SAVE IT
• Optional - You can change at this point the host name of the RPi. I use the same name that's being used in the squeezelite settings as squeezelite player name - SAVE IT

 


I know. This "SAVE IT" gets a bit annoying. But that's how it's done. Once you are finished
with all this run a "Reboot". After that check if all settings are still there! To me it happened more than once that I thought I'd be done...

pCP Kernel Tweaks

Now we'll have a closer look at the "Kernel Tweaks" menu. That's a key section. It's getting serious!


 

CPU Governor

Linux offers CPU frequency scaling. It's quite  a dynamic kernel feature that controls the kernel frequencies on a load situation basis. There are different profiles (governors) you can choose from. 

The default governor is "ondemand".  That one changes the CPU clock frequency dynamically between  600MHz and 1500MHz on RPi4.
We don't want that dynamic up'n down scaling. A stable and steady operation is preferred.
The realtime-kernel development team also recommends to stay away from dynamic up'n down scaling.
That's why we go for the "performance" governor. That one nails the CPU to the maximum default CPU frequency (RPi 4 1500MHz).

With the RPi 4 in place we stick to 1500MHz operation. In the past I used to run my systems at 1000MHz. Not anymore.

Overclock

Click on the "Advanced Overclock" menu and you'll end up here:


 

Overclock!?!? Advanced!?!?

Nope. We're not overclocking the CPU. 

At this stage we just set "Force turbo" to "Yes". This settings dives a little deeper then the earlier addressed "performance" governor - you can compare this setting now with a BIOS setting.
However. It basically does the same thing as the performance governor. It locks the CPUs at the maximum CPU frequency - which is 1500MHz. 

Save it!

CPU Isolation

Back to the  "pCP Kernel Tweaks" section.  As you can see there is a feature called "CPU Isolation"



This feature allows to isolate CPUs from being accessed randomly by userspace applications. Radom in a sense that the kernel scheduler decides on its own where to put the tasks.
The isolated CPUs will sit idle once being isolated. In general you can assign a program or a thread (subprogram) to a specific CPU. That's a common OS feature.
If you then assign that program manually to an isolated CPU, it'll run on that CPU exclusive - without distraction! And that's what we're looking for.

We use the isolation feature for our purposes, trying to increase the system efficiency. First of all we assign the output thread of squeezelite to the isolated CPU3.

This is IMO one of the most powerful tweak to increase the efficiency of our system on the "last mile":

You can see in above screenshot that I recommend to isolate CPU3 AND CPU2. What for!?!?

NOTE: I had to omit the CPU0 Isolation method I've been proposing before Jan-31-2021 . The RPi 3 and 4 won't support CPU0 isolation anymore! I've been in touch with the RPi kernel designer about the issue. At this stage he is not willing to change it. 

Now we assign the squeezelite main process and the remaining threads to CPU2. That leaves all

the remaining processes, interrupts etc. on CPU 0 and 1.

Another note: While testing this feature it turned out that there's a flaw on pCP, which prevents that squeezelite main process isolation is working. pCP-Paul promised to get it fixed soon.

LMS (Logitech Media Server)

The pCP LMS menu can be left alone for now. It becomes relevant for running a RPi 4 as audio server.
And guess what. Since 2020 and the RPi4 im running LMS on a PI.

Conclusion

You made it. That'll be it for the time being. If you've followed above recommendations your system should be well on its way by now!


Let's not rest for too long!


There's still quite some stuff to do.