Dockerising openWakeWord

[dalehumby]

I run Rhasspy in Base/Satellite mode. Currently each Satellite captures audio, does the wake word detection and streams audio to the Base which does everything else. My Pi4 satellite runs the Rhasspy Docker container, launched with compose. My Base Rhasspy container is runon a much more pwerful i7 with loads of RAM (also runs other home automation software.)

I've been thinking of Docerising OWW, and then using Rhasspy 2.5's Hermes MQTT to send data from the Rhasspy container to OWW container, do the detection and send the result back on MQTT again. For Rhasspy 3 we could build an adapter that sends audio via e.g. a UDP or websocket stream.

Other API options could also be provided for those who don't use Rhasspy.

Running OWW in Docker eases distribution and setup (Python dependencies), allows OWW to develop at a separate pace to Rhasspy (instead of being bundled and released with Rhasspy). The single instance of OWW container could be run on a more powerful base station PC which all satellites use for wake word detection, allowing lower power satellites (ESP32) richer wake word options.

OWW could present a web UI for configuration: which words to detect, thresholds, custom verifier models and maybe speaker identification

It could also have a live demo built in for testing and diagnostics.

@dscripka what have your thoughts been on integrating OWW and Rhasspy more easily?

[dalehumby]

I've had a go at Dockerising openWakeWord, still a WIP (and I need to build and upload images onto Dockerhub), but the basic UDP audio receiving from Rhasspy, and triggering wake word via MQTT(Hermes protocol) is working.

https://github.com/dalehumby/openWakeWord-rhasspy

[dscripka]

Making a Docker image for openWakeWord was definitely somewhere on the backlog, and I certainly agree with your line of thinking regarding integrating with other libraries and frameworks (Rhasspy, OVOS, etc.).

Thanks for creating an initial Docker file and associated serving code, it looks quite good! Once there are some features in openWakeWord that will benefit from a web UI it should be an simple extension to add that to the Docker file so it's easily accessible.

Would you mind if I linked to your repo in the openWakeWord Readme as an example of other deployment options?

[dalehumby]

Would you mind if I linked to your repo in the openWakeWord Readme as an example of other deployment options?

Sure!

Next I want to add ability to have multiple input audio threads, one for each satellite. Possibly also be able to receive audio over MQTT Hermes... although I am less sure of its use, maybe it's easier for users to set up because they don't need to fiddle with UDP ports, and using MQTT we could auto-discover satellites.

I haven't looked into OVOS, or had a solid explore of Rhasspy 3 yet.

I'm more than happy to take input on what would be useful to add to this "wrapper".

[dalehumby]

Quick update:

• I've configured a GitHub action to push Docker images to Docker Hub. Currently linux/amd64 and linux/arm64. Any others I should support?
• Refactored the code to use a thread for each UDP audio stream and a prediction thread. Multiple satellites all sending audio, and a centralised wake-word service is now supported.
• Added some filtering to only trigger Rhasspy once, and help reduce false positives even more.
• Readme with full instructions

[jenskastensson]

Thanks @dalehumby , if possible, supporting armv7 would be interesting.

[dalehumby]

Hi @jenskastensson – I added armv7 to the build file, but it's failing on installing requirements, I think at numpy. (Only had a brief look.)

I don't have 32-bit Raspberry Pi OS installed on any of my Pi's to debug this. Do you? If you can figure out what changes to make to requirements, Dockerfile or build process I'll be happy to update the repo.

Maybe @dscripka knows whether it's even possible to run openWakeWord on armv7?

[jenskastensson]

Thanks Dale, I tried on my side and had the very same build error. I'm not sure what the issue might be, any ideas to workaround it would be appreciated @dscripka !
lscpu
Architecture: armv7l
Byte Order: Little Endian
CPU(s): 4
On-line CPU(s) list: 0-3
Thread(s) per core: 1
Core(s) per socket: 4
Socket(s): 1
Vendor ID: ARM
Model: 5
Model name: Cortex-A7
Stepping: r0p5
CPU max MHz: 1008.0000
CPU min MHz: 480.0000

[dscripka]

Looking at the build logs from @dalehumby, it seems like the issue is that there are not arm32 pre-built packages for some of the dependencies (at least numpy, probably others). It's likely possible to install the necessary build dependencies into the container, but it might take some additional effort.

There also might be pre-built versions of these packages hosted elsewhere that can be used, but that would also require modifying the build process.

Beyond these issues though, there shouldn't be other problems with running openWakeWord on arm32 platforms.