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?
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?
'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.
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
.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
Last edited:
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
PeppyMeter
With sudo most probably there is no the alsaplugin. You could check hexdump myfifo
Last edited:
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?
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
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
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'.
[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'.
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"}
{"audio-device": "alsa/default", "video": false, "cache": "no"}
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
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
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.
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?
What is the difference?
The latter works with my pi installation, but does not with your image
Could you explain?
>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
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
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.
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.
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
Maybe it's something to catch at.
Edit: I didn't rebuild the so, just got from peppyalsa-master
Last edited:
Yes, it should. I'll test that later on. I hope you know that libpeppyalsa.so is a symbolic link.