Running linux-voice-assistant on Raspberry Pi 2B (armhf/armv7l) — Full Guide

[caledhwa]

Running linux-voice-assistant on Raspberry Pi 2B (armhf/armv7l) — Full Guide

Hardware

• Raspberry Pi 2B (armv7l / armhf — 32-bit)
• Blue Yeti USB Microphone
• Headphones via Pi 3.5mm jack

---

Problem 1: Wrong ELF class — libtensorflowlite_c.so is x86-64

Error:

OSError: .../pymicro_wakeword/lib/libtensorflowlite_c.so: wrong ELF class: ELFCLASS64

The pymicro-wakeword PyPI wheel (and even the linux_armv7l wheel from piwheels) ships an x86-64 libtensorflowlite_c.so. The upstream source for this library is https://github.com/tphakala/tflite_c, which only publishes linux_amd64, linux_arm64, darwin_arm64, and windows_amd64 — no armhf build.

Fix: Cross-compile from source on an x86 machine using Docker

The TFLite version used is v2.17.1 (confirmed via tphakala/tflite_c release tags).

Run this on a Mac or Linux x86 machine with Docker:

docker run --rm -v /tmp/tflite_out:/output \
  debian:bookworm bash -c "
    apt-get update && \
    apt-get install -y gcc-arm-linux-gnueabihf g++-arm-linux-gnueabihf cmake git python3 && \
    git clone --depth 1 --branch v2.17.1 https://github.com/tensorflow/tensorflow /tf && \
    cat > /tmp/armhf.cmake << 'EOF'
set(CMAKE_SYSTEM_NAME Linux)
set(CMAKE_SYSTEM_PROCESSOR armv7l)
set(CMAKE_C_COMPILER arm-linux-gnueabihf-gcc)
set(CMAKE_CXX_COMPILER arm-linux-gnueabihf-g++)
set(CMAKE_C_FLAGS \"-march=armv7-a -mfpu=neon-vfpv4 -mfloat-abi=hard -O2\")
set(CMAKE_CXX_FLAGS \"-march=armv7-a -mfpu=neon-vfpv4 -mfloat-abi=hard -O2\")
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
EOF
    mkdir /tf/build && cd /tf/build && \
    cmake ../tensorflow/lite/c \
      -DCMAKE_BUILD_TYPE=Release \
      -DTFLITE_ENABLE_XNNPACK=OFF \
      -DCMAKE_TOOLCHAIN_FILE=/tmp/armhf.cmake && \
    cmake --build . --target tensorflowlite_c -- -j\$(nproc) && \
    cp libtensorflowlite_c.so /output/
  "

Verify it's correct:

file /tmp/tflite_out/libtensorflowlite_c.so
# ELF 32-bit LSB shared object, ARM, EABI5 ...
readelf -A /tmp/tflite_out/libtensorflowlite_c.so | grep "VFP\|float"
# Tag_ABI_VFP_args: VFP registers  <-- required for armhf

Copy to the Pi:

scp /tmp/tflite_out/libtensorflowlite_c.so \
  pi@<your-pi>:/home/pi/linux-voice-assistant/.venv/lib/python3.13/site-packages/pymicro_wakeword/lib/libtensorflowlite_c.so

---

Problem 2: Wake word never detects — uint8 quantization bug

Symptom: The service starts, mic audio is received, but the wake word never triggers. All TFLite inference returns probability 0.0000.

Root cause: A bug in pymicro_wakeword/microwakeword.py line 207. The quantization formula uses input_zero_point = -128, which produces values in the range [-128, 127]. Casting this to np.uint8 silently clips all negative values to 0, completely corrupting the input tensor. Inference runs successfully but on garbage data, producing all-zero output.

# BUGGY (line ~207 in microwakeword.py):
quant_features = np.round(
    np.concatenate(self._features, axis=1) / self.input_scale
    + self.input_zero_point
).astype(np.uint8)   # <-- wrong! clips negative values to 0

# FIXED:
quant_features = np.round(
    np.concatenate(self._features, axis=1) / self.input_scale
    + self.input_zero_point
).astype(np.int8)    # <-- correct for INT8 quantized models

Fix:

sed -i 's/\.astype(np\.uint8)/.astype(np.int8)/g' \
  .venv/lib/python3.13/site-packages/pymicro_wakeword/microwakeword.py

Note: This bug affects any platform where the model's input_zero_point is negative (i.e. INT8 quantized models). It is not armhf-specific — it would silently break inference on any architecture.

---

Problem 3: Audio input device not selected

The service defaulted to no explicit input device. With PulseAudio, the device name must match exactly what soundcard reports. Add to /etc/systemd/system/linux-voice-assistant.service:

Environment=AUDIO_INPUT_DEVICE=Blue Microphones Analog Stereo
Environment=AUDIO_OUTPUT_DEVICE=pulse/alsa_output.platform-3f00b840.mailbox.stereo-fallback

To find the correct name for your device:

source .venv/bin/activate
python3 -c "import soundcard as sc; [print(m.name, '|', m.id) for m in sc.all_microphones()]"

---

Problem 4: Wrong wake word configured

preferences.json defaulted to okay_computer and hey_mycroft. Update it:

{
    "active_wake_words": ["okay_nabu"],
    "volume": 1.0,
    "thinking_sound": 1
}

Also note: the wake word model file is named okay_nabu (not ok_nabu).

---

Additional notes

• pyopen_wakeword/lib/libtensorflowlite_c.so also ships as x86-64 with the same BuildID. If you switch to the openWakeWord engine, the same .so replacement procedure applies.
• The micro_features_cpp feature extractor (pymicro-features package) installs correctly as a 32-bit armhf binary from piwheels — no fix needed there.
• Building TFLite natively on the Pi 2B is possible but extremely slow and will fail if the device has no internet access during the CMake dependency download phase.

[caledhwa]

Folks, I worked pretty hard with copilot on this solution and holey crap, it works! I had a bunch of problems getting the HA to recognize the device, but that was because it was never fully starting because the pyopen_wakeword/lib/libtensorflowlite_c.so was still 64 bit after compiling, once that happened, HA auto-recognized it. However, the really BIG problem was a type mismatch for 32-bit in microwakeword.py and lo-and behold after a bunch of debugging with claude-sonnet-4.6 it gave me a patch fix for it and holey moely, it works!!!! I have a Raspberry Pi 2b with an 8GB SD card using a Blue Microphone for in, and just the headphone jack on the pi for out. The HA Assist is running against a bunch of pipeline running on a Mac Mini. It seems to perform pretty well - good enough. So, now I can use this device! :)

[danielholm]

Thank you for this and well done! I gave it a go once to get support on a pi zero (1), but gave up. Will try.