Friday, January 19, 2018

Raspberry Pi - The Audio Engine - Part 2 - piCorePlayer settings

In "Part 2" of this series I'd like to cover the pCP settings. The setup of choice follows
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 accessI 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.

Wifi/Bluetooth

Next comes the Wifi settings.

We'll turn off 

1. Wifi and 
2. Bluetooth




Save it!


Basic Tweaks


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.



Save it!


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 
the PI.




Note: Not just the Alsa output level is saved, all Alsa mixer control stats are saved.

Save it!

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. 

Let's get that under control.


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





Overclock!?!?  Advanced!?!?

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. 


Save it!

CPU Isolation

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.


1 comment:

  1. Hi,
    wouldn´t be a good thing to add suggestion of updating the system through "Full Update" at the start of this tutorial?

    ReplyDelete