my overall philosophy "less shall be more". I'm targeting a no frills, high efficiency and smooth running setup.
Just to remind you. All settings assume a RPI 3B(+) as base and also assume you're running pCP40. With slight adaptations this or that setting can also be applied to the other RPI models.
I further assume that the PI runs as headless playback engine only.
Meaning. There's a separate LMS server out there in the network and there's no screen attached.
And it is also assumed that the RPI is attached to the net via cable. (See my networking proposal) -
Update Nov-17-2018: With the introduction of RPI 3B+ I switched to onboard WLAN as network access. I describe the story behind it and the wireless setup later in a different article.
Hint. Don't forget to push the "save" buttons as soon as you've done your changes - pCP offers many of these buttons. ;)
Squeezelite and pCP restarts and reboot several times during the process.I know - it's a bit annoying.
Let's start with the Main Window.
We switch to Beta at the bottom to be able to access all options.
I forgot. How do we get to the pCP main menu ??
Once you've powered and booted up the RPI with the SD-card inserted,
you "just" enter the IP address into your web browser of choice on whatever client (PC/iOS/Android)
Got you. How do we find out that IP address? Your best bet is a login to your router. Look for a menu that shows connected clients in the network. If you've found your device, the smartest thing would be to select "reserve IP address" for your RPI.
This way you'll get the same IP address assigned to your RPI once and forever!
Once this is done you can connect via browser and bookmark that RPI-pCP link for your next access!
We continue from here with our initial setup
Actually there's nothing to be done on the main screen.
Squeezelite settings are covered in Part 3 of this series. We can skip that for now.
Next comes the Wifi settings.
We'll turn off
1. Wifi and
Next comes the pCP System Tweaks section.
1. I turn off piCorePlayer Tabs
2. and LMS controls
3. Then we turn off HDMI, which will save us about 20mA current consumption.
Alsamixer persistent settings
Now we configure pCP to keep our Alsamixer settings. You don' want to redo all
mixer settings and that includes e.g. DAC mode and filter settings every time you reboot
Note: Not just the Alsa output level is saved, all Alsa mixer control stats are saved.
CPU Frequency Scaling
Now we'll have a closer look at the "Kernel Tweaks" menu.
Linux offers CPU frequency scaling. There are different profiles (governors) you can choose from.
The default governor is "ondemand". That one changes dynamically the CPU clock frequency between a min and a max value. We don't want that dynamic up'n down switching. The rt-kernel patch team also recommends to stay away from dynamic switching.
That's why we go for the "performance" governor. That one nails the CPU at maximum frequency.
Now we run into a slight issue. The CPUs will run at max frequency (e.g. 1400MHz on 3B+) all the time. That generates a hell lot of load (power), heat and probably noise.
For basic audio streaming we don't need such a high CPU clock frequency.
Click on the "Advanced Overclock" menu and you'll end up here:
Nope. We're not overclocking the CPU. We're actually "underclocking" it. Even that is the wrong expression. We're simply throttling the CPU and GPU frequencies down to values
within the officially allowed frequency spectrum.
pCP offers underclocking profiles. These are RPI model specific predefined profiles.
The RPI 3B(+) will run at 800MHz and the GPU at 200MHz. That's still more than sufficient for the streaming job and saves us close to 300mA. (That's actually a profile setting I recommended towards the pCP team - more advanced users can still edit these settings via terminal)
At this stage we also set "Force turbo" to "Yes". This settings dives a little deeper then the earlier discussed "performance" governor - you can compare it 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 800MHz if you select the "underclocking" profile
on the 3B(+). This setting can not be overwritten by any of the userspace governors anymore!
Actually these Overclock/underclocking settings are all a kind of BIOS settings. The governor settings are kernel settings through the userspace.
NOTE: There's a BUG in pCP40
To get the profile "Under" properly to work, 1st choose "Lowest" profile press "Save" and then "Under" and press "Save" again!!! That'll do.
You can estimate 50-60mA/100MHz (CPU under load) difference on power consumption.
Since we don't use a GPU on a headless client we configure the GPU memory to its minimum = 16MB.
As you can see in above "pCP Kernel Tweaks" screenshot , there is a new feature(> pCP4.0) called "CPU Isolation"
We can use this for our purposes, to increase the system efficiency and to make the system running a little smoother.
You can see above that I isolated CPU0 and CPU3. What for!?!?
On the RPI all HW interrupts are associated to CPU0. You can't change that. On my PC setups I used to play around with the so called "CPU affinities", and not just for processes, I also changed IRQ affinities.
My idea for the RPI was now if I can't move IRQs, we just isolate them. That's why there's a "0" in the field. After doing that no SW process can access that CPU0 anymore. All IRQs will have an exclusive playground to enjoy!
The 2nd idea was to assign squeezelite, actually just the output task, to a certain CPU and isolate it against any other processes. And that's what we do by also isolating CPU3. And then assigning the "Squeezelite Output CPU" to that CPU "3".
It's not needed to assign the main squeezelite process to a fixed CPU.
Thx to the pCP team to make this feature accessible via GUI!
That'll be it for the time being.
The pCP LMS menu can be left alone.
Next comes the squeezelite and audio interfaces setup.