I have used Snowboy on a Pi Zero with my own code before and had very low resource usage. Additionally, Rhasspy still uses a ton of CPU on the Zero even with different wakeword engines.
Maybe @tuxedo78 is on to something?
Looks very like he has found where the load is and well tracked down.
I can confirm that commenting the same lines on one of my Pi Zeros has reduced CPU usage significantly. My Snowboy wakeword and audio record/play still works great and all seems more responsive as a result.
Going 1 step further…
With the webserver not running (as explained above), I now have my CPU fully eaten by snowboy… Following the advice of @3issa, I move to snowboy wakeword instead of jarvis… and it makes a BIG difference 
Faster and more responsive while I have random responsiveness with jarvis.umdl. Thanks for the good tip
Now I’ll move to using custom wake word in order to try optimizing further…
By the way I don’t observe relevant performance difference between docker and venv, only some difference in Pyaudio config for my Jabra 410. Therefore, I’ll start using only the docker container as I find it easier to manage for auto-start when the Pi zero starts up.
fx
Interesting. I am using a custom wakeword with snowboy (.pmdl) instead of one of their universal models and I have low CPU usage (~10% when the Rhasspy webserver is disabled). Maybe that makes a difference?
There certainly is a difference between pmdl and umdl wakeword. Jarvis.umdl size is 3.5MB, my personnal wakeword size is about 10kB. Jarvis has multiple embedded hotwords that makes it heavier.
Thanks to @tuxedo78 for his useful workaround, that makes a big difference. With 2 personnal wakewords my rpi zero now runs with about 25 % CPU load.
@synesthesiam is it possible to have a way to enable/disable the webserver through commandline for future versions? That would really help for Pi-zero… And by leaving more CPU cycles to wakeword (especially for snowboy), I really think that it should improve wakeword detection performance.
fx
1 Like
+1 for this for 2.5, if possible @synesthesiam. Even an environment variable or command line argument or something that could be included in my docker-compose.yaml to disable the webserver would be amazing. Once I have everything on my Pi Zero satellite configured (using external MQTT), there’s no need for me to be running the web server.
Hello,
Yes, I do not understand this saturation, when:
mosquitto_sub -v -h “localhost” -p 12183 -t “#”
2.5 on Odroid xu4
I’ll add an option to rhasspy-voltron to disable the web server. Let’s see if that helps. I’ve also noticed supervisord sometimes leaves behind running Rhasspy processes. Do you see anything after exiting with ps -ef | grep rhasspy?
All my sites (Pi0, Pi3B+ and VM/master) run in Docker and I have never observed processes still running after stop.
Regarding this option, please could you elaborate the exact impacts of disabling the web server? Is it pure configuration stuff (need to change profile.json manually which is quite OK) or does it impact binding with external programs like Jeedom?
Well I checked and disabling web server will completly break Jeedom interface so not an option for me 
Oh, yeah. Jeedom uses the HTTP and websocket APIs extensively.
Can you tell if the CPU usage is coming specifically from the web server’s Python process?
Yes this is definitely coming from the webserver because even with an install from scratch (deleted .config/rhasspy directory), the load is high (25% on Pi-zero without anything is really unexpected) despite there is no running service.
If you have any clue how to dig into the Quart webserver server, I can give it a try…
Not really. Anyone know a good Python profiler?
well the webserver could be disabled only for sattelites ( but it would be nice to have a way to manage/config the sattelites from the server )
Can confirm that there are no supervisord “left-behind” processes for me either. On my Pi Zero, the CPU usage is coming from a python process, not a rhasspy-* process. So when I comment out the app.run() lines in rhasspyserver_hermes/__main__.py and restart the container, the CPU usage is much more manageable. I don’t use Jeedom and have a purely external MQTT setup, so it has made my satellites much more responsive.
The web server shouldn’t be burning so much CPU, so this may be a bug. I’m worried it’s processing a lot of unnecessary MQTT messages.
Are you using UDP for you wake word audio, or MQTT (the default)?
I’m using UDP on my satellites.
1 Like