PeppyMeter

[SergeG]

What else mpd-user could have that pi-user has not?
Any?
What else a general service could have that regular user has not?
TTY bindings?
Any random ideas would be helpful. ;-)


For instance
in mpd.log
: curl: icy-metaint=8192 (for pi)
: curl: icy-metaint=16000 (for mpd)
Could it be meaningful?

 

[rpi]

'mpd' definitely has more permissions than 'pi' user. I still cannot find what that can be. 'pi' also belongs to the same 'audio' group. Not only 'mpd' but 'vlc' also runs without spikes with 'sudo'. I thought it would be easier to find those extra privileges for 'mpd' but it looks like that's not so easy I'm not sure about that icy stuff.

 

[SergeG]

Silly me!. ;-)
.asoundrc is read from home folder.
The alsaplugin containing .asounrc is in pi’s home only.
So running as service, as mpd, there will be a different home, where there is no asoundrc and so no alsaplugin. So problems with pi, and no problems with mpd.

Moving the alsaplugin containing asondrc to /etc/ asonund.conf produces the same spikes while running in the name of mpd-user
:-((


Edit: under root as well – spikes :-(
So lets forget the permissions and get back to the entire system

 

[rpi]

I've just double checked 'vlc' and confirm that there are no spikes with 'sudo' and there are spikes without 'sudo'. You can try it yourself just install packages for 'sudo':
PeppyMeter

 

[SergeG]

With sudo most probably there is no the alsaplugin. You could check hexdump myfifo

 

[rpi]

I've tried the same with mpd and the result was the same - no spikes with 'sudo' and spikes without 'sudo'. I'm not sure what is your point about alsa plugin?

 

[rpi]

Hmm, it looks like you are right - with 'sudo' there is no data in the pipe.

 

[SergeG]

Move the alsaplugin containing asondrc to /etc/asonund.conf
and check again.
Zero output from "hexdump /home/pi/myfifo" while playing means there is no alsaplugin used, i.e. no spikes by definition.
I’ve checked with /etc/asonund.conf (with alsaplugin) and experienced spikes with any user, and the both vlc (standalone) and mpd

 

[rpi]

OK, so the only workaround right now is to disable the network caching.

 

[SergeG]

Not yet for me ;-)

 

[rpi]

Select 'vlc' in the players.txt file and disable caching:

[vlc.linux]
server.start.command = --aout=alsa --alsa-audio-device=default --verbose=-1 --network-caching=0

I don't know how to do the same for 'mpd'.

 

[rpi]

Unlike in 'vlc' the following configuration for 'mpv' doesn't help to get rid of the CPU spikes:
{"audio-device": "alsa/default", "video": false, "cache": "no"}

 

[SergeG]

How do you think why

libpeppyalsa.so can be loaded from /usr/local/lib
but not from /home/pi
The permissions are the same.


In my asound.conf it's succesfull from /home/pi/libpeppyalsa.so

 

[rpi]

Serge, when you say the permissions are the same do you mean 'root' permissions? '/home/pi' is the home for 'pi' user. I don't think that the 'root' files placed in that folder will be accessible by 'pi' user.

 

[SergeG]

Your libpeppyalsa.so differs from the peppyalsa-master one.
What is the difference?
The latter works with my pi installation, but does not with your image
Could you explain?

 

[SergeG]

>permissions are the same do you mean 'root' permissions?


rwxr-xr-x for all of them. Who cares about the owner. Is there a any difference?


I was able to use a /home/pi/ libpeppyalsa.so (your one, not from peppyalsa-master), but I had to rename usr/local/lib to /usr/local/qwe

I understand nothing :-(


Constantly recalling that killing python3 on the system start ruins the networking, the machine got inaccessible. It's reproducible, I faced that 3 times

There is something strange with the image

 

[rpi]

The library in the image was created by following these steps on Raspberry OS:
Installation * project-owner/peppyalsa.doc Wiki * GitHub

I think if you follow the same instructions and use Raspberry OS you should get the same library. The only difference which I can think of is the different versions of dependencies which you get after system update/upgrade.

 

[SergeG]

Should the peppyalsa-master one work with your image? It doesn't
Maybe it's something to catch at.


Edit: I didn't rebuild the so, just got from peppyalsa-master

 

[rpi]

Yes, it should. I'll test that later on. I hope you know that libpeppyalsa.so is a symbolic link.

 

[SergeG]

>is a symbolic link
I'm newbie with linux, but hope not an imbecile ;-)