PeppyMeter

[SergeG]

Re-flashed the SD. It's OK so far.

Should I expect Web UI available by default?

 

[SergeG]

>http://IP_OF_YOUR_PI:8080


8000, not 8080 ;-)

 

[SergeG]

Sorry, I have to surprise you once more.
I killed no processes and didn’t touch anything at all. Just connected via Web UI, switched radio stations and had no significant spikes at all. CPU jumps from 10% to 15-18% for a second.
The Pi4 performance is higher than Pi3 I believe, but anyway 18% for second is not 100% for 20 seconds.
Shouldn’t you check your hardware, use a memtest or reflash the image?


Edit: I could check something else, just tell me what exactly

 

[rpi]

Have you used .asoundrc for the peppyalsa plugin? Just replace .asoundrc by the one available in /home/pi folder

 

[SergeG]

I was able to reproduce at last.
So far the findings
if mpd log is verbose there are


Jul 16 14:36 : exception: OutputThread could not get realtime scheduling, continuing anyway: sched_setscheduler failed: Operation not permitted


and (sometimes but often)


Jul 16 14:42 : playlist: play 5:"http://icy1.abacast.com/krtu-krtufmaac-96"
Jul 16 14:42 : exception: Failed to decode http://icy1.abacast.com/krtu-krtufmaac-96
Jul 16 14:42 : exception: nested: CURL failed: Connection timed out after 10008 milliseconds


The latter is not critical I believe.
Thinking about the first I tried to launch mpd in the name of user-mpd as it should be started by default OS installation, but failed.
Maybe it’s the key but my Linux knowledge is definitely not enough for that.
How to check the problem with mpd start as user-mpd


Edit

Also iotop reveals some correlations with top (jbd2 kernel thread)

 

[SergeG]

Also switching between the stations doesn’t cause the same spikes always
Sometimes it happens smoothly, couldn’t catch a regularity so far

 

[SergeG]

Is there a tool to show CPU consumption by processes but separately for user and kernel mode?

 

[rpi]

Hi Serge,

This is good news. Well, I mean bad good news that you can reproduce the issue
I'm not sure that using 'pi' user vs 'mpd' makes any difference because 'vlc' and 'mpv' were also used with 'pi' user. And they also have this issue.

To switch from 'mpd' user to 'pi' user I do the following steps when prepare disk image:

Stop mpd as a system service:
sudo service mpd stop
sudo update-rc.d mpd disable
sudo systemctl disable mpd
sudo systemctl disable mpd.socket
sudo systemctl disable mpd.service
sudo rm /usr/lib/systemd/user/mpd.service
sudo rm /etc/xdg/autostart/mpd.desktop

sudo chown pi /usr/bin/mpd
sudo chgrp audio /usr/bin/mpd

mkdir -p /home/pi/.config/mpd/playlists
create new mpd.conf - all paths point to new folder ~/.config/mpd
change user to pi, add section for fifo, change mixer
alsa device: default
or 
wget [URL]https://raw.githubusercontent.com/project-owner/Peppy.doc/master/files/mpd.conf[/URL]
mv mpd.conf ~/.config/mpd

I've never used any profilers other than 'perf' which I used recently. The result output from it you can find in one of my previous posts.

 

[SergeG]

Believe me or not, but running mpd as root produces no spikes anymore.
I’ve been very actively switching the stations for already 30 minutes
It’s time to check what
------
Jul 16 14:19 : exception: RTIOThread could not get realtime scheduling, continuing anyway: sched_setscheduler failed: Operation not permitted
Jul 16 14:19 : exception: OutputThread could not get realtime scheduling, continuing anyway: sched_setscheduler failed: Operation not permitted
-------
means. It was while running as pi, but not as root



To be honest I did before
apt-get update/upgrade
and
apt-get remove/install mpd
Not sure it was relevant. Running mpd as pi didn’t reveal any improvements

 

[rpi]

I was able to reproduce the same behavior with 'vlc'. I installed the required packages using 'sudo':

sudo pip3 install mutagen
sudo pip3 install discogs_client
sudo pip3 install pexpect
sudo pip3 install Pillow
sudo pip3 install pynanosvg
sudo pip3 install feedparser
sudo pip3 install python-vlc
sudo pip3 install tornado==4.5.3

Then started the player with 'sudo':
sudo python3 peppy.py
and didn't see spikes.
When I start without 'sudo':
python3 peppy.py
I see the spikes.

I'm not sure what that means though

 

[phofman]

Clearly root has permission to request realtime scheduling, unlike the pi user. Realtime scheduling changes the timing details and the high-CPU load condition does not occur (which is most likely just by coincidence). IMO that just confirms that very likely the load does not occur at startup (on which realtime scheduling has no effect), but during runtime processing.

I still think the meaningful (i.e. not trial/error) way forward is profiling the code. E.g. GPROF Tutorial – How to use Linux GNU GCC Profiling Tool + rebuilding alsa-lib with the -gc parameter, perhaps using dpkg-buildflags dpkg-buildflags(1) — dpkg-dev — Debian testing — Debian Manpages

 

[rpi]

Is it possible just to grant the missing privileges to the 'pi' user?

 

[phofman]

E.g. How do I configure my linux system to allow JACK to use realtime scheduling? | JACK Audio Connection Kit - setting rtprio for the user or complete audio group.

 

[SergeG]

A postulate first. We are not going to patch all the players, neither write our own one. Right?
So we just have to satisfy the “requirements” or suffer the spikes.


I think mpd creates its own user not accidentally.
What is inside mpd of the exception.
Mpd has a couple of threads that try to call SetThreadRealtime.
The latter requires permissions above pi-user has, I guess
SetThreadRealtime() effectively calls syscall(__NR_sched_setscheduler, pid=0, sched, param)
in MPD-master\src\thread\Util.cxx
Looks like (i’m not guru with Linux though) the kernel needs more permissions to serve that.
As the result proper thread scheduling serves the streams better.


IMHO what to do
- run the players as root. I see it’s not the best idea,
- investigate what permissions mpd-user finally has and (maybe) run all the other players in the name of the same account. Or create a similar your own one and run the player in the name of the account. Or give up the spikes because of the “postulate” above.


Understanding the __NR_sched_setscheduler related requirements would be useful as well,
but it’s beyond my possibilities at the moment. If you could shed some lite, I would be happy. I’m curious.

 

[rpi]

Per that page I've created the file:
sudo nano /etc/security/limits.d/peppy.conf
with this content:

@peppy   -  rtprio     95
 @peppy   -  memlock    unlimited

Then:

sudo groupadd peppy
sudo usermod -a -G peppy pi
sudo reboot

I still see the spikes.

 

[SergeG]

E.g. How do I configure my linux system to allow JACK to use realtime scheduling? | JACK Audio Connection Kit - setting rtprio for the user or complete audio group.

So doing as "Editing the configuration file" could give enough permissions for pi most probably.

 

[SergeG]

>I still see the spikes.


We have a checkpoint - exceptions in (verbose) mpd.log

 

[rpi]

Serge, I did a lot to avoid running the player under 'sudo'. I hope that finding the right permissions which we need to grant to the 'pi' user should solve the problem.

 

[phofman]

Honestly, I do not think setting the rtpriority is a bugfix. It may cause the circumstances for the problem to not arise (different timing), but certainly not a fix.

 

[rpi]

phofman, now I'm not sure that we have a bug at all. Why do you think so?