>hope we all agree that CPU utilization over 100% for about 20 seconds is not normal because
Sorry, a note. One core from 4 only. You may want to use (sudo) htop to see the per-core loading.
>that blocks almost all other running tasks for that period of time.
Definitely not all other tasks, just reduces the potential to 75%
(Pi4 has 4 cores, and only one of them is overloaded)
Sorry, a note. One core from 4 only. You may want to use (sudo) htop to see the per-core loading.
>that blocks almost all other running tasks for that period of time.
Definitely not all other tasks, just reduces the potential to 75%
(Pi4 has 4 cores, and only one of them is overloaded)
Serge, you are right regarding CPU cores. I just see the consequences of the issue in UI - it becomes unresponsive. Is it running on the same core as player/ALSA I don't know.
phofman, you can try to use 'mpv' without my code. It's installed on the disk image. I've never ran it outside of the player though. So I'm not sure how to simulate switching between radio stations from the command line. That's including vlc.
phofman, you can try to use 'mpv' without my code. It's installed on the disk image. I've never ran it outside of the player though. So I'm not sure how to simulate switching between radio stations from the command line. That's including vlc.
Last edited:
Yes, here is that file. You can see configurations for each player there:
Peppy/players.txt at master * project-owner/Peppy * GitHub
The device should be 'default' instead of 'hw'
For vlc and mpv I use Python bindings, for mpd not.
Peppy/players.txt at master * project-owner/Peppy * GitHub
The device should be 'default' instead of 'hw'
For vlc and mpv I use Python bindings, for mpd not.
Last edited:
That boundary value is the maximum memory position reachable by the pointer in the slave (plug plugin or directly hw:X), it is not the buffer defined by alsa clients. It is a very low-level parameter which definitely should not be tinkered with. It does not belong to the meter but to the slave defined in the meter section of asoundrc.
Clearly there is a bug in the logic of assigning the size value. I have yet to learn more about the app/hw pointers, delays etc. Actually this learning more about the most inner alsa functions is my motivation to fix this issue
Clearly there is a bug in the logic of assigning the size value. I have yet to learn more about the app/hw pointers, delays etc. Actually this learning more about the most inner alsa functions is my motivation to fix this issue
I tried to learn more details about the boundary issue pcm_meter.c issue at s16_update . The core problem is that application pointer can be lowered at any time by pcm rewinding as well as by boundary wraparound. While rewinding could be caught somewhere in the meter plugin, I do not think the boundary wraparound is detectable.
IMO the easiest "bugfix" is resigning on proper detection of these changes and complicated adjustment of the meter/scope buffer pointers, and simply skipping converting the samples from last run by this trivial patch:
IMO old samples will be used for vu-meter for that cycle.
Unfortunately I did not find a way to view the vu-meter in the web ui, the screensaver never appeared. Thus I could not check if skipping the conversion of those several hundred samples does not do any visual quirk, but IMO the next update cycle (defined by the configured meter update frequency) the conversion continues from correct positions.
The alsa-lib fprintf goes to mpd log (~/.config/mpd/mpd.log) for checking the frequency of the "bugfix".
If the vu-meter works OK, I would send a patch proposal to alsa. I do not know if it will be accepted as it is still a hack (yet much better than nothing ).
IMO the easiest "bugfix" is resigning on proper detection of these changes and complicated adjustment of the meter/scope buffer pointers, and simply skipping converting the samples from last run by this trivial patch:
Code:
--- a/src/pcm/pcm_meter.c
+++ b/src/pcm/pcm_meter.c
@@ -1098,8 +1105,11 @@ static void s16_update(snd_pcm_scope_t *scope)
snd_pcm_sframes_t size;
snd_pcm_uframes_t offset;
size = meter->now - s16->old;
- if (size < 0)
- size += spcm->boundary;
+ if (size < 0) {
+ fprintf(stderr, "s16_update meter->now dropped compared to previous run (meter->now %ld, s16->old %ld), skipping the update\n", meter->now, s16->old);
+ s16->old = meter->now;
+ return;
+ }
offset = s16->old % meter->buf_size;
while (size > 0) {
snd_pcm_uframes_t frames = size;IMO old samples will be used for vu-meter for that cycle.
Unfortunately I did not find a way to view the vu-meter in the web ui, the screensaver never appeared. Thus I could not check if skipping the conversion of those several hundred samples does not do any visual quirk, but IMO the next update cycle (defined by the configured meter update frequency) the conversion continues from correct positions.
The alsa-lib fprintf goes to mpd log (~/.config/mpd/mpd.log) for checking the frequency of the "bugfix".
If the vu-meter works OK, I would send a patch proposal to alsa. I do not know if it will be accepted as it is still a hack (yet much better than nothing
).
Last edited:
>I did not find a way to view the vu-meter in the web ui,
You may want to install peppymeter, a pretty standalone python3 application.
>I do not know if it will be accepted as it is still a hack
For me the problem occurs on the default sound card and never happens on the others (including snd-dummy). Could it be a point to be taken into consideration. i.e. why that boundary issue happens on selected sound cards only? Different sound card’s buffer size?
You may want to install peppymeter, a pretty standalone python3 application.
>I do not know if it will be accepted as it is still a hack
For me the problem occurs on the default sound card and never happens on the others (including snd-dummy). Could it be a point to be taken into consideration. i.e. why that boundary issue happens on selected sound cards only? Different sound card’s buffer size?
phofman, thanks a lot for the new workaround! This is the very low level fix. It reminds me the change which I made in the peppyalsa.c about 1.5 years ago:
Durer Edition * project-owner/peppyalsa@f462d28 * GitHub
I had a 'segmentation fault' without this code. I'm not sure if this is related to the current issue.
The cache disabling is the high level fix, Serge's solution with dummy sound card is the middle level and the fix in the ALSA is the low level fix. If the latter one works fine I'll use it with disk images. I'll recommend to use two other solutions for the stand-alone installations.
I'm going to start working on PeppyMeter modifications during this weekend. I'll recompile ALSA with the suggested change and test it.
Thank you all!
Durer Edition * project-owner/peppyalsa@f462d28 * GitHub
I had a 'segmentation fault' without this code. I'm not sure if this is related to the current issue.
The cache disabling is the high level fix, Serge's solution with dummy sound card is the middle level and the fix in the ALSA is the low level fix. If the latter one works fine I'll use it with disk images. I'll recommend to use two other solutions for the stand-alone installations.
I'm going to start working on PeppyMeter modifications during this weekend. I'll recompile ALSA with the suggested change and test it.
Thank you all!
I've tested the change in the pcm_meter.c file. I haven't observed any CPU usage spikes. Also I haven't seen any side effects. The meters worked as expected.
As I mentioned already I'll build libasound library with that workaround and use it with disk images for the Peppy player. For those who will install the software without disk image there are two other workarounds available: either disable network cache in the player (mpd, vlc and mpv) or use dummy sound card.
phofman and Serge, thanks a lot for finding the workarounds and for your time which you spent on that! I appreciate that and consider this help as the good example of the collaboration on the open source project.
Now I need to fix the slowness in the circular meters. That's a different story...
Best regards
As I mentioned already I'll build libasound library with that workaround and use it with disk images for the Peppy player. For those who will install the software without disk image there are two other workarounds available: either disable network cache in the player (mpd, vlc and mpv) or use dummy sound card.
phofman and Serge, thanks a lot for finding the workarounds and for your time which you spent on that! I appreciate that and consider this help as the good example of the collaboration on the open source project.
Now I need to fix the slowness in the circular meters. That's a different story...
Best regards
>to fix the slowness in the circular meters
Rpi: I’ve made some progress on that. All of my achievements are already available to you. If you need my comments as well – welcome
>I'll build libasound library with that workaround
Rpi: Could you please sent me the (release) build, I would update libasound on my Pi.
Rpi: I’ve made some progress on that. All of my achievements are already available to you. If you need my comments as well – welcome
>I'll build libasound library with that workaround
Rpi: Could you please sent me the (release) build, I would update libasound on my Pi.
Hi Serge,
Yes I have your datasource.py file. During the weekend I implemented a configurable smoothing buffer. So that the current volume level will be calculated using the previous values. The size of the buffer can be changed in the config.txt file. The default buffer size is 4. It looks like only this change was enough to solve the most issues. Now the meter indicators move smoothly. By increasing/decreasing the buffer size it's possible to change that smoothness.
Also I changed the polling interval for all meters. There is no need to update the meter more often than the screen frame rate (frames-per-second). Assuming that the fps is usually 30 for the most SPI touchscreens the polling interval should be 0.033 seconds. Before that for some meters I had interval 0.005 seconds which doesn't make sense. This change allowed to reduce the CPU utilization. Now the meters add only about 6% max to the CPU usage. Before that change the number was about 20%-40% or even higher.
I'm still working on the changes for the next Peppy player release. So the images will be available whenever I make the release. Meanwhile you can download the libasound library with the fix here:
Peppy.doc/libasound.so.2.0.0 at master * project-owner/Peppy.doc * GitHub
Place it in the folder /usr/lib/arm-linux-gnueabihf/
Best regards
Yes I have your datasource.py file. During the weekend I implemented a configurable smoothing buffer. So that the current volume level will be calculated using the previous values. The size of the buffer can be changed in the config.txt file. The default buffer size is 4. It looks like only this change was enough to solve the most issues. Now the meter indicators move smoothly. By increasing/decreasing the buffer size it's possible to change that smoothness.
Also I changed the polling interval for all meters. There is no need to update the meter more often than the screen frame rate (frames-per-second). Assuming that the fps is usually 30 for the most SPI touchscreens the polling interval should be 0.033 seconds. Before that for some meters I had interval 0.005 seconds which doesn't make sense. This change allowed to reduce the CPU utilization. Now the meters add only about 6% max to the CPU usage. Before that change the number was about 20%-40% or even higher.
I'm still working on the changes for the next Peppy player release. So the images will be available whenever I make the release. Meanwhile you can download the libasound library with the fix here:
Peppy.doc/libasound.so.2.0.0 at master * project-owner/Peppy.doc * GitHub
Place it in the folder /usr/lib/arm-linux-gnueabihf/
Best regards