Open JamesOldigesOther opened 4 weeks ago
Consolidating this thread.
I have it somewhat "working"
v1.16.3
and latest numpy < 2.0
(For Wyoming Satellite)./tensorflow/lite/tools/pip_package/build_pip_package_with_cmake.sh native
Environment="LD_PRELOAD=/usr/lib/arm-linux-gnueabihf/libatomic.so.1.2.0"
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.
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