Of course should not…. Maybe it's because the system was not fully loaded yet.
I faced that ssh or ping attempts made "too soon" could ruin the networking.
I mean with your image. It shouldn’t, I see….May be a coincidence. I didn’t investigate the details, a different problem is in the focus ;-)
I faced that ssh or ping attempts made "too soon" could ruin the networking.
I mean with your image. It shouldn’t, I see….May be a coincidence. I didn’t investigate the details, a different problem is in the focus ;-)
I installed fresh Headless disk image and checked the size and functionality of the peppyalsa plugin:
I saw the same notorious CPU spikes.
Then I installed the plugin from the Githib by following these instructions:
Installation * project-owner/peppyalsa.doc Wiki * GitHub
Everything was working and the same spikes are there.
Code:
$ ls -l /usr/local/lib/libpeppyalsa.so.0.0.0
-rwxr-xr-x 1 root root 50688 Jun 2 04:22 /usr/local/lib/libpeppyalsa.so.0.0.0Then I installed the plugin from the Githib by following these instructions:
Installation * project-owner/peppyalsa.doc Wiki * GitHub
Code:
$ ls -l /usr/local/lib/libpeppyalsa.so.0.0.0
-rwxr-xr-x 1 root root 50688 Jul 20 00:02 /usr/local/lib/libpeppyalsa.so.0.0.0>The library for the disk image was compiled on Pi 3. As far as I remember you are using Pi 4. I'm not sure that the binaries are compatible.
Nevertheless libpeppyalsa.so of 52600 bytes 07-03-19 works on my PI4 installation, but does not on the this image.
>Where can I set -pg flags for recompiling alsa-lib? Is there any "master" Makefile?
Sorry, no ideas. I don’t think recompiling/fixing alsa is the right way.
There is a risk of “drowning” in alsa. As the last remedy maybe only.
Meanwhile I’m trying the “old-school” method on peppyalsa.
Nevertheless libpeppyalsa.so of 52600 bytes 07-03-19 works on my PI4 installation, but does not on the this image.
>Where can I set -pg flags for recompiling alsa-lib? Is there any "master" Makefile?
Sorry, no ideas. I don’t think recompiling/fixing alsa is the right way.
There is a risk of “drowning” in alsa. As the last remedy maybe only.
Meanwhile I’m trying the “old-school” method on peppyalsa.
Fixing alsa is the only right way should the problem be in alsa 
I am not saying recompiling with different compiler flags will be trivial. But IMO combination of dpkg-buildflags(1) — dpkg-dev — Debian testing — Debian Manpages , HowToGetABacktrace - Debian Wiki and GPROF Tutorial – How to use Linux GNU GCC Profiling Tool could do.
I am not saying recompiling with different compiler flags will be trivial. But IMO combination of dpkg-buildflags(1) — dpkg-dev — Debian testing — Debian Manpages , HowToGetABacktrace - Debian Wiki and GPROF Tutorial – How to use Linux GNU GCC Profiling Tool could do.
I'm not sure that we can fix the alsa but I hope that we should be able to see where it spends the most time when CPU spike occurs. So that instead of the hexadecimal reference it would show the function name here:
PeppyMeter
I hope that '-pg' flags for compiler could help here.
PeppyMeter
I hope that '-pg' flags for compiler could help here.
Yes, I can successfully compile and install it by following these steps:
Updating ALSA on Raspbian Stretch
It just doesn't show function names when I run 'perf' tool as in the link which I mentioned above. It just shows hexadecimal pointers. I thought that if I compile it with debugging symbols enabled it would show function names like snd_super_function instead of 0x5e884. I'm not so familiar with C/C++ build system. More likely the 'configure' script should be changed and executed to generate all Makefiles...
Updating ALSA on Raspbian Stretch
It just doesn't show function names when I run 'perf' tool as in the link which I mentioned above. It just shows hexadecimal pointers. I thought that if I compile it with debugging symbols enabled it would show function names like snd_super_function instead of 0x5e884. I'm not so familiar with C/C++ build system. More likely the 'configure' script should be changed and executed to generate all Makefiles...
Rpi: Being totally perplexed by the problem I switched back to my Raspberry image.
libpeppyalsa.so of 52600 bytes 07-03-19 works fine without any spikes still
(this .so crashes mpd on your image, if you remember).
Then I decided to rebuild libpeppyalsa.so from the sources, got 50688 bytes .so, but it does not work – no data in the pine.
I switched several times from 52600 to 50688 bytes libpeppyalsa.so and didn’t touch anything else. The first works perfectly and no spikes, the second doesn’t at all.
So do you have an idea for what could be wrong in the build procedure.
Were there changes in the source? I downloaded the sources from GitHub - project-owner/peppyalsa (as Download ZIP)
libpeppyalsa.so of 52600 bytes 07-03-19 works fine without any spikes still
(this .so crashes mpd on your image, if you remember).
Then I decided to rebuild libpeppyalsa.so from the sources, got 50688 bytes .so, but it does not work – no data in the pine.
I switched several times from 52600 to 50688 bytes libpeppyalsa.so and didn’t touch anything else. The first works perfectly and no spikes, the second doesn’t at all.
So do you have an idea for what could be wrong in the build procedure.
Were there changes in the source? I downloaded the sources from GitHub - project-owner/peppyalsa (as Download ZIP)
Hi Serge, I've tried to use that 52600 library and it also crashed with my latest image. Probably I should not distribute binaries I don't even remember on which OS it was compiled. Also the versions of the dependencies can differ from the current ones. That can explain why fails on the current image.
The main problem is that you cannot use the library which you compile yourself. I didn't change the build process for 2 years.
I have verified one more time on my Turner disk image (Pi 3) that if I follow all steps described here:
Installation * project-owner/peppyalsa.doc Wiki * GitHub
it works fine for me. I use git but it should not make difference. I'd recommend to clean up the lib folder:
sudo rm -rf /usr/local/lib/libpeppy*
delete source folder and repeat the build process. Make sure that you don't see the errors. You can ignore warnings.
I hope Pi 4 should not make any difference. I believe you also use 32-bit Raspberry OS. Is it Lite version?
I don't even remember on which OS it was compiled. Also the versions of the dependencies can differ from the current ones. That can explain why fails on the current image. The main problem is that you cannot use the library which you compile yourself. I didn't change the build process for 2 years.
I have verified one more time on my Turner disk image (Pi 3) that if I follow all steps described here:
Installation * project-owner/peppyalsa.doc Wiki * GitHub
it works fine for me. I use git but it should not make difference. I'd recommend to clean up the lib folder:
sudo rm -rf /usr/local/lib/libpeppy*
delete source folder and repeat the build process. Make sure that you don't see the errors. You can ignore warnings.
I hope Pi 4 should not make any difference. I believe you also use 32-bit Raspberry OS. Is it Lite version?
Hi Rpi,
Have you found something the spikes related? It’s the main problem actually ;-)
Did you reach success with profiling ALSA
> I've tried to use that 52600 library and it also crashed with my latest image.
It’s linked to libm for an unclear reason. Maybe it’s the key. Libm exists and is of the same version on the both systems though. How could I check why 52600 library crashes. With ldd I could find the difference is in libm linkage only. How to investigate such problems in general on Linux.
>The main problem is that you cannot use the library which you compile yourself. I didn't change the build process for 2 years.
Actually after several attempts the newly compiled library started working.
I reached the success by compiling with
gcc -shared meter.c peppyalsa.c spectrum.c -lfftw3 -lasound -o libpeppyalsa.so
first. It’s a miracle for me. A high energy photon struck the PI, ;-)
Anyway no spikes with the recompiled libpeppyalsa in my (native) system.
>sudo rm -rf /usr/local/lib/libpeppy*
Maybe that helped, I can’t recall unfortunately.
>I hope Pi 4 should not make any difference. I believe you also use 32-bit Raspberry OS. Is it Lite version?
Good question ;-) I was installing choosing the default (recommended) image from “Raspberry Pi Imager”, It’s 32 bit, not sure there are 64-bit OSes available/recommended. Not sure about the Lite.
Most probably it was full version. Could it be the key for spikes?
Have you found something the spikes related? It’s the main problem actually ;-)
Did you reach success with profiling ALSA
> I've tried to use that 52600 library and it also crashed with my latest image.
It’s linked to libm for an unclear reason. Maybe it’s the key. Libm exists and is of the same version on the both systems though. How could I check why 52600 library crashes. With ldd I could find the difference is in libm linkage only. How to investigate such problems in general on Linux.
>The main problem is that you cannot use the library which you compile yourself. I didn't change the build process for 2 years.
Actually after several attempts the newly compiled library started working.
I reached the success by compiling with
gcc -shared meter.c peppyalsa.c spectrum.c -lfftw3 -lasound -o libpeppyalsa.so
first. It’s a miracle for me. A high energy photon struck the PI, ;-)
Anyway no spikes with the recompiled libpeppyalsa in my (native) system.
>sudo rm -rf /usr/local/lib/libpeppy*
Maybe that helped, I can’t recall unfortunately.
>I hope Pi 4 should not make any difference. I believe you also use 32-bit Raspberry OS. Is it Lite version?
Good question ;-) I was installing choosing the default (recommended) image from “Raspberry Pi Imager”, It’s 32 bit, not sure there are 64-bit OSes available/recommended. Not sure about the Lite.
Most probably it was full version. Could it be the key for spikes?