Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CPU Usage maxed and no functionality on Raspberry Pi 0w #30

Open
JamesOldigesOther opened this issue Aug 15, 2024 · 1 comment
Open

Comments

@JamesOldigesOther
Copy link

I've gone ahead and compiled TF-Lite for the Raspi Architecture without much issue. However, in running it in conjunction with Wyoming-Sattelite, OpenWakeWord is using 100% of the CPU.

As far as I can tell, it isn't functional/functioning

Without OpenWakeWord, I'm able to interface as expected with Wyoming Satellite only.

I am running it with the debug flag, though my console messages are largely lacking
ExecStart=/home/james/wyoming-openwakeword/script/run --uri 'tcp://127.0.0.1:10400' --debug

Aug 15 19:22:27 Debra02 systemd[1]: Started wyoming-openwakeword.service - Wyoming openWakeWord.
Aug 15 19:22:35 Debra02 run[4544]: DEBUG:root:Namespace(uri='tcp://127.0.0.1:10400', models_dir=PosixPath('/home/james/wyoming-openwakeword/wyoming_openwakeword/models'), custom_model_dir=[], preload_model=[], threshold=0.5, trigger_level=1, output_dir=None, debug=True, log_format='%(levelname)s:%(name)s:%(message)s', debug_probability=False, version=False, model=[])
Aug 15 19:22:35 Debra02 run[4544]: DEBUG:root:Loading /home/james/wyoming-openwakeword/wyoming_openwakeword/models/melspectrogram.tflite
Aug 15 19:22:35 Debra02 run[4544]: DEBUG:root:Loading /home/james/wyoming-openwakeword/wyoming_openwakeword/models/embedding_model.tflite
Aug 15 19:22:35 Debra02 run[4544]: INFO:root:Ready
Aug 15 19:22:35 Debra02 run[4544]: DEBUG:wyoming_openwakeword.handler:Client connected: 110594151777903
Aug 15 19:22:35 Debra02 run[4544]: DEBUG:root:Loading ok_nabu_v0.1 from /home/james/wyoming-openwakeword/wyoming_openwakeword/models/ok_nabu_v0.1.tflite
Aug 15 19:22:35 Debra02 run[4544]: DEBUG:wyoming_openwakeword.handler:Started thread for ok_nabu_v0.1
Aug 15 19:22:36 Debra02 run[4544]: Error in cpuinfo: failed to parse file /sys/devices/system/cpu/cpu0/topology/physical_package_id: "-1
Aug 15 19:22:36 Debra02 run[4544]: " is not an unsigned number
Aug 15 19:22:43 Debra02 run[4544]: DEBUG:root:Loading ok_nabu_v0.1 from /home/james/wyoming-openwakeword/wyoming_openwakeword/models/ok_nabu_v0.1.tflite
Aug 15 19:22:43 Debra02 run[4544]: DEBUG:wyoming_openwakeword.handler:Started thread for ok_nabu_v0.1
Aug 15 19:22:43 Debra02 run[4544]: DEBUG:wyoming_openwakeword.handler:Sent info to client: 110594151777903

@Joldiges
Copy link

Consolidating this thread.

I have it somewhat "working"

  1. ONNX-runtime will build on-target (or qemu docker) on version v1.16.3 and latest numpy < 2.0 (For Wyoming Satellite)
  2. tflite-runtime was a pain. build on-target (or qemu docker) with the command ./tensorflow/lite/tools/pip_package/build_pip_package_with_cmake.sh native
    1. You'll need to add this to your service to link libatomic Environment="LD_PRELOAD=/usr/lib/arm-linux-gnueabihf/libatomic.so.1.2.0"
  3. you'll need to change the wyoming-openwakeword setup (or your pip config) to install the local instance of your newly compiled tflite-runtime.

For days and days of work, it resolved to be quite simple. A lot of wasted time was attempted cross-compiling the complex build systems. Lesson learned.

Unfortunately, the CPU is maxed out and the actual wake-word capturing is... not right.
I'm getting consistently low readings
Aug 17 01:22:03 Debra02 run[2193]: DEBUG:root:client=3665034168370, wake_word=ok_nabu_v0.1, probability=0.0009...
But when I say the keyword it does (consistently raise the probability slightly
Aug 17 01:22:03 Debra02 run[2193]: DEBUG:root:client=3665034168370, wake_word=ok_nabu_v0.1, probability=0.0011...

My anticipation is that it's taking longer to process the audio clip than the time between them, cutting off the processing.

But my assumption is that I can't really change the sample rate, because the real metric is "processing faster than real life"
Therefore, the solution would be to process a "simpler" model, which is outside of my scope. I hope someone may read this and pick up where I've left off, or guide me on how to proceed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants