PeppyMeter

[rpi]

I've added logging to the peppyalsa plugin and found that there is no any plugin activity when audio player is caching data and when CPU usage is high. So I'm not sure if anything can be done on the plugin side regarding this issue. The only workaround right now is to disable caching on player side. I know how to do that for vlc (--network-caching=0) but cannot find cache settings for mpd and mpv. If anybody knows that please let me know.

 

[SergeG]

>Why should user mpd have access to /home/pi/myfifo?


I think because of
- mpd starts in the name of mpd user (by default, PepppyPlayer configures it differently)
- alsa plugin is loaded by mpd, so in the name of mpd as well
- the plugin has to write data to the pipe (to be caught by PepppyMeter)

 

[phofman]

SergeG: You are perfectly right, the user running the MPD process must have access to the FIFO. But does really user mpd have access to home directory of user rpi in order to write into /home/pi/myfifo? I would be very surprised if it did because that would require changing access permission to /home/pi directory - a very non-standard operation.

 

[phofman]

When a cached data will reach some threshold (e.g. 10% of the cache size) the sound goes to ALSA/speakers. The CPU issue which I observe lasts for the duration of the whole caching not only the initial 10%.

I've added logging to the peppyalsa plugin and found that there is no any plugin activity when audio player is caching data and when CPU usage is high.

I do not understand during which caching stage you detect no plugin activity - the initial fill to the threshold (e.g. mplayer default has 20%)? That would make sense because until the threshold is reached the output device is closed. Afterwards a regular playback occurs. However, when the fill drops below the threshold, typically players call snd_pcm_pause/snd_pcm_resume.

Still I do not understand when the high CPU load stops.The cache should never be filled to 100% because if it did, the player would have to start some correction - dropping samples (mplayer does that), changing asynchronous resampling etc.

MPV caching params are mpv.io

 

[phofman]

rpi: Did you try the default alsa scope meter whether the problem is not in the PCM meter layer of alsa-lib, before your plugin?

 

[SergeG]

>So I'm not sure if anything can be done on the plugin side regarding this issue.


“Patching” players doesn’t look as a good solution, imo
Maybe it could be used if nothing else helps, but….. It’s a remedy for consequences, not for genuine problem


You have started the problem discussion from “disabling alsa plugin solves the problem”. Correct?
So the influence exists, it may be indirect, but exists anyhow.


I would first try to create the same plugin with _all_ the payload commented to check whether the influence still exists.
If there is no more influence I would try to carefully uncomment it back “line-by-line” to find a minimal part of code adding that recovers the problem back.
If the influence still exists I would check the plugin initialization carefully, maybe a required “flag” is just missed.
Also reviewing your asoundrc I saw some roughness in the ctl processing chain.
As pcm.default is myequal, ctl.default should be myequal as well. Not sure it’s so important, but who knows, the problem is strange.
Btw, did you try a simple (default) asoundrc?





> When a cached data will reach some threshold (e.g. 10% of the cache size) the sound goes to ALSA/speakers.


Sorry, not too convincing, the caching happens inside the player solely, correct?
When the player decides “it’s enough”, it starts sending the data to alsa.
I might miss something important, but how the fact of caching touches the playing process?
I see the fact is, but is there a “theory”

 

[SergeG]

>require changing access permission to /home/pi directory - a very non-standard operation.


Right theoretically, but looks like it’s not the problem relevant, rather a separate investigation related. However practically the folder permissions are “surprisingly” enough.


>I do not understand when the high CPU load stops
>Did you try the default alsa scope meter


We reason the same way

 

[phofman]

Right theoretically, but looks like it’s not the problem relevant, rather a separate investigation related. However practically the folder permissions are “surprisingly” enough.

I am sorry I do not understand, please can you reword? IIUC your setup in system-wide /etc/asound.conf works for rpi user, root user, and not for mpd user. Your system-wide setup uses a file accessible only by rpi and root users. How could it work for the mpd user too when the fifo pipe location is not accessible by the playback process?

 

[SergeG]

>setup in system-wide /etc/asound.conf works for rpi user, root user, and not for mpd user.


Not exactly. It works for mpd user but partially, say so.
The Rpi’s config sets the alsa processing chain as pcm.default → equal → peppyalsa.
Mpd is targeted to pcm,default as well. Mpd works with peppyalsa, I see data in the pipe and PeppyMeter’s needles are moving. But “alsamixer -D equal” adjustments take no effect for mpd.
However “alsamixer -D equal” adjustments perfectly work for aplay (pi user) and “sudo aplay” (root). The config is always one and only - /etc/asound.conf

I can’t understand what could prevent “alsamixer -D equal” from working with mpd user (mpd itself)






> Your system-wide setup uses a file accessible only by rpi and root users. How could it work for the mpd user too when the fifo pipe location is not accessible by the playback process?


Maybe home/pi permissions are more wide (not as you expected). I have to verify.


Edit:

Verified
The pipe has prw-rw-rw- 1 pi pi
so write permissions for mpd exist.
Why do you think the pipe writing could require permissions to /home/pi folder. Imo mpd doesn’t need to access the folder at all

Probably I misunderstood you.

 

[phofman]

In any case the system-wide pipe location would be better in /var/run, /var/tmp or /tmp as these directories are writable by any user.

Some setups (e.g. ubuntu) can keep homes readable by other users, but definitely should not make it writable.

My test user can read from fifo in a different home, but cannot send data to the pipe:

test@precision:~$ cat /home/pavel/myfifo 
^C
test@precision:~$ echo whatever > /home/pavel/myfifo 
bash: /home/pavel/myfifo: Permission denied

The asound.conf defines no pcm.equal device, yet ctl.equal is defined. I would suggest to make it paired with your pcm device. (ctl.myequal).

As of the alsamixer -D equal not working - do I understand correctly, that your alsa chain runs under mpd user, yet you are trying to access the control elements of your chain (i.e. running alsamixer) under rpi user? I am afraid it does not work like that, the devices are per user. Running under a different user creates a new device for that particular user.

Try this simple test:

cat /etc/asound.conf 
pcm.myequal {
type equal;
slave.pcm plughw:3
}

ctl.myequal {
  type equal;
}

Now play with equal controls under one user (e.g. rpi, or any in a different linux) alsamixer -D myequal and check the changes with amixer in a different terminal amixer -D myequal contents . If amixer runs under the same user, you will see the changes. If amixer runs under a different user (e.g. mpd), changes in alsamixer have no effect - the other user creates a different alsa chain with same name (local to the user).

 

[phofman]

>
The pipe has prw-rw-rw- 1 pi pi
so write permissions for mpd exist.

OK I did not assume you would set everyone-write permissions to a file in your home folder. That's what system-wide shared folders are for.

 

[SergeG]

[FONT=Liberation Mono, monospace][FONT=Liberation Mono, monospace]>[/FONT][FONT=Liberation Mono, monospace]In any case the system-wide pipe location would be better in /var/run, /var/tmp or /tmp as these directories are writable by any user. [/FONT][/FONT]


[FONT=Liberation Mono, monospace][FONT=Liberation Mono, monospace]You are right. I just faced Linux for the first time about 2 months ago for the only purpose – PI based player, so it’s not a multi user system for sure. Now my PI player just works.Anyway, thank you, next time I need to patch the player I will move the pipe to a more proper [/FONT][FONT=Liberation Mono, monospace]location.[/FONT][/FONT]


[FONT=Liberation Mono, monospace][FONT=Liberation Mono, monospace]>The asound.conf defines no pcm.equal device, yet ctl.equal is defined. I would suggest to make it paired with your pcm device. (ctl.myequal).[/FONT][/FONT]


[FONT=Liberation Mono, monospace][FONT=Liberation Mono, monospace]My purpose was to reproduce the problem reported by Rpi.[/FONT][/FONT]
[FONT=Liberation Mono, monospace][FONT=Liberation Mono, monospace]I wasn’t able to reproduce but found some irregularity in ctl.* that Rpi may want to check as his problem is really strange.[/FONT][/FONT]
[FONT=Liberation Mono, monospace][FONT=Liberation Mono, monospace]My regular asound.conf is different and contains no equalizers.
[/FONT][/FONT]




[FONT=Liberation Mono, monospace][FONT=Liberation Mono, monospace]>[/FONT][FONT=Liberation Mono, monospace]your alsa chain runs under mpd user, yet you are trying to access the control elements of your chain (i.e. running alsamixer) under rpi user? [/FONT][/FONT]


[FONT=Liberation Mono, monospace][FONT=Liberation Mono, monospace]Oops, silly me, of course, thank you![/FONT][/FONT]
[FONT=Liberation Mono, monospace][FONT=Liberation Mono, monospace]I was under impression the equalizer is a system wide one, “exactly” as a hardware EQ connected to the same PI. So just had wrong expectations.
[/FONT][/FONT]
[FONT=Liberation Mono, monospace][FONT=Liberation Mono, monospace]Thanks once more! [/FONT][/FONT]
[FONT=Liberation Mono, monospace][FONT=Liberation Mono, monospace]
[/FONT][/FONT]

[FONT=Liberation Mono, monospace][FONT=Liberation Mono, monospace]Lets get back to the main subject and wait for Rpi reply[/FONT][/FONT]
[FONT=Liberation Mono, monospace][FONT=Liberation Mono, monospace] [/FONT][/FONT]

 

[phofman]

I am sorry for being too harsh at times. You are doing great job, not giving up.

 

[rpi]

Some history could probably help to better understand the issue. First time I faced the issue in the Peppy player where I’m using the PeppyMeter and Spectrum Analyzer as the screensavers. I found that when you switch radio stations the UI becomes unresponsive - you need to wait for 15-20 seconds after button press. The audio is not affected. The new station starts playing almost right away. I checked CPU usage and found that it goes over 100% after switching stations. It goes to normal after about 15-20 seconds. When it goes to normal UI becomes responsive again until the next station change. Because of that issue I changed the PeppyMeter and Spectrum data source from ‘pipe’ to ‘noise’ and postponed the investigation. Now I decided to chase the issue again…

There is no plugin activity for the duration of the high CPU usage - 15-20 seconds. When CPU usage starts going to normal e.g. from 120% to 80% the plugin starts output to the pipe.

In some mpd doc I read that it caches data for 20 seconds of the playback. So if you disconnect the network cable it will continue playing for 20 seconds.

I also thought that there are two variables in this line ’scopes.0 peppyalsa’. How can I test that scopes.0 part? If I comment out the whole there is no issue.

phofman, Thank you for the mpv cache settings.

Serge, I agree that it would be better to fix the issue if possible rather than change players cache settings. I’m just not sure how much of my and your time I should spend on this issue

There is no issue with simple .asoundrc without equalizer and peppyalsa. Also no issue with equalizer and without peppyalsa.

I don’t have the link to any doc explaining caching mechanism in any player. I can only derive it from the settings. One of the players (mpd ?) has a setting which defines in cache size percent when to start the playback.

Serge, you can try to reproduce the issue using links to radio streams instead of files. Then switch the stream using mpc for example. You can get the links from this playlist:
Peppy/stations.m3u at master * project-owner/Peppy * GitHub

I will continue debugging later on today.

Thanks a lot for helping out!

 

[SergeG]

> I’m just not sure how much of my and your time I should spend on this issue


Undoubtedly the level of perfectionism is up to you solely. ;-)


Commenting ’scopes.0 peppyalsa’ switches the plugin off, completely off? Am I right?
It’s the key to be understood in full. i.e. what exactly happens when the line is commented.


>There is no issue with simple .asoundrc without equalizer and peppyalsa. Also no issue with equalizer and without peppyalsa.


What would be with peppyalsa but without equalizer?
In order to investigate the problem the less third parties (e.g. EQ) the better.


>you can try to reproduce the issue using links to radio streams instead of files.


Will be back on the results

 

[rpi]

As I mentioned if I comment out the line 'scopes.0 peppyalsa' the issue goes away. I'm not sure that 'scopes.0' can cause the issue as I also tested another .asoundrc without 'scopes.0' and without equalizer:
Configuration * project-owner/peppyalsa.doc Wiki * GitHub
The issue was there with that file as well.

It looks like the plugin opens some black hole which attracts CPU cycles I thought that maybe plugin goes to some tight/infinite loop. But there are no any loops in the code:
peppyalsa/meter.c at master * project-owner/peppyalsa * GitHub
peppyalsa/peppyalsa.c at master * project-owner/peppyalsa * GitHub

 

[SergeG]

>you can try to reproduce the issue using links to radio streams instead of files.


With my mpd, my asound and your radio.m3u - no spikes at all while switching the radio stations.

>The issue was there with that file as well.


You may want to comment all the payload in the plugin keeping the skeleton (the initialization) only, rebuild the plugin and try.
This would check whether the plugin initialization affects.

 

[phofman]

rpi: Did you try the stock alsa meter/scope to see if the problem is not somewhere in the alsa-lib shim for meter plugins?

 

[rpi]

Serge, do you use .asoundrc mentioned in this post?
PeppyMeter


phofman, how can I test that 'meter' stuff?

 

[phofman]

I did not realize there was no official meter plugin distributed as part of alsa-lib. Then trying e.g. ameter or the other meter plugins you have used as base for your version.