Hight CPU usage after client disconnect
Closed this issue · 6 comments
While working on https://gist.github.com/roblan/1a373b5a3414a464b53a140f55dab058 I've notice that when I pause music there is very high CPU usage in this script.
Have I done something wrong or it's Pi VU Meter fault?
I'm guessing it's this super-tight loop that's causing the problem:
https://github.com/pimoroni/pivumeter/blob/devel/python_server/socket_server.py#L136-L148
You might want to add a time.sleep(0.001) or something similar before each instance of break in that loop, that should prevent it running unbounded and CPU-hungry. There's probably a much better way to accomplish this.
I've done a simple debbuging - log here https://github.com/pimoroni/pivumeter/blob/devel/python_server/library/pivumeter/__init__.py#L72 and here https://github.com/pimoroni/pivumeter/blob/devel/python_server/library/pivumeter/__init__.py#L133 but they are logged only when music is playing so it looks like it's not that...
Trying to revive this old thread. I've created the clone of the ameter/pivumeter:
https://github.com/project-owner/peppyalsa.doc/wiki
I replaced I2C output by the named pipe output. That allows to separate software and
hardware implementations:
https://github.com/project-owner/PeppyMeter.doc/wiki/Outputs
I have faced almost all issues reported for the pivumeter. Recently I fixed the Segmentation Fault
issue described here:
#16
Here is the fix:
https://github.com/project-owner/peppyalsa/blob/master/src/peppyalsa.c#L111
Now I'm experiencing high CPU usage issue which terribly slows down my application.
Did you debug further this issue? Thank you!
@project-owner sorry for the radio silence- I've had so many other things to do that attempting to improve PiVUMeter has taken a back seat. I'm glad you took this code and ran with it- I was hoping it would gain more traction in the Pi community than it did, and invite some people to solve some of the long standing issues.
In what cases are you experiencing a high CPU usage? I suspect the sheer volume of audio frames, coupled with the need to run each through a fast-fourier transform probably isn't optimal but then it's not like dozens of music players haven't already done this since WinAmp. It should be a solved problem.
I could venture that my code - me not really being a C/C++ developer, and certainly not a very experienced one around the time I wrote it - probably has some room for improvement.
Hi Philip, thank you for reply even one year later :) I also put VU Meter on hold after facing that issue and focused on another stuff.
As far as I remember the issue with high CPU usage usually occurred during track change. After some period of time it went back to normal. The CPU usage was about 150%, which means that one core was 100% and the second one 50% busy. I don't think this is normal. My wild guess - there is some kind of buffering issue. I'm just not sure at which level it happens - audio player, plugin, FFT or anywhere else.
I was planning to start working on this issue. If I'll find any other info I'll let you know. If you will find any info/fix please let me know.
Thank you!
Since Raspberry Pi OS has rolled out (if I'm remembering correctly) Pulse Audio now it might be prudent to look into adapting pavumeter to replace the ALSA plugin part of pivumeter.
I dare say, I've not touched this code for so long that I'm likely only to break it further!
Closing this for now, with the hope of finding some time to explore a better, more robust alternative!