Reachy Mini Not Speaking

# ai# iot# linux# openai
Reachy Mini Not SpeakingKrunal Chavda

Reachy Mini Not Speaking in Reachy Mini Conversation App— GStreamer DeviceMonitor Fails...

Reachy Mini Not Speaking in Reachy Mini Conversation App— GStreamer DeviceMonitor Fails Without PipeWire/PulseAudio

Before you jump in

Make sure to check that you have not run out OpenAI api credits or reachy is not on low battery. Sometimes both of those issues lead him to act differently.

The Problem

Your Reachy Mini Wireless robot connects to the OpenAI Realtime API successfully, dances, plays emotions, and calls tools autonomously — but it never speaks or responds to your voice. The robot appears to be "talking to itself," cycling through idle behaviors like do_nothing reason=contemplating existence with zero speech interaction.

The system logs show the conversation app launching cleanly with the session connected, but two critical warnings buried in the startup output reveal the root cause:

WARNING reachy_mini.media.audio_gstreamer:470 | No Source audio card found.
WARNING reachy_mini.media.audio_gstreamer:470 | No Sink audio card found.
Enter fullscreen mode Exit fullscreen mode

No Source means no microphone input. No Sink means no speaker output. The Realtime API session is alive on the control channel, but no audio flows in either direction — so the model never hears you and never generates speech.

The Confusing Part

Here's what makes this bug hard to diagnose: the audio hardware works perfectly at the OS level.

Running arecord -l and aplay -l shows "Reachy Mini Audio" as card 0 with both capture and playback subdevices. Recording and playing back audio via ALSA command-line tools works fine:

arecord -d 3 -f S16_LE -r 16000 /tmp/test.wav
aplay /tmp/test.wav
Enter fullscreen mode Exit fullscreen mode

GStreamer can also use the ALSA device directly with no issues:

gst-launch-1.0 alsasrc device=hw:0 num-buffers=10 ! fakesink
Enter fullscreen mode Exit fullscreen mode

So the hardware is fine, ALSA is fine, and GStreamer can talk to the card. The problem is specifically in how the Reachy Mini SDK discovers the audio device.

Root Cause

The SDK's audio backend (reachy_mini/media/audio_gstreamer.py) uses GStreamer's Gst.DeviceMonitor to enumerate audio devices. The _get_audio_device() method creates a monitor, filters for Audio/Source or Audio/Sink, and then iterates through discovered devices looking for one named "Reachy Mini Audio."

The detection logic tries multiple property fields in order:

  1. node.name — for PipeWire
  2. device.api / device.id — for Windows (WASAPI)
  3. unique-id — for macOS
  4. udev.id + device.profile.name — for Linux PulseAudio
  5. device.string — for Linux ALSA fallback

The problem: GStreamer's DeviceMonitor returns zero devices when neither PipeWire nor PulseAudio is running. The Reachy Mini Wireless runs a minimal Debian installation on a Raspberry Pi 4 with pure ALSA — no audio server layer. When the monitor finds nothing to enumerate, the method falls through to the warning log and returns None, leaving the conversation app with no audio capability.

You can confirm this by running a quick Python check on the robot:

import gi
gi.require_version('Gst', '1.0')
from gi.repository import Gst
Gst.init(None)
monitor = Gst.DeviceMonitor()
monitor.add_filter('Audio/Source')
monitor.start()
print(monitor.get_devices())  # Returns empty list
monitor.stop()
Enter fullscreen mode Exit fullscreen mode

The Fix

The fix is a two-line patch to audio_gstreamer.py that adds an ALSA hardware fallback when the DeviceMonitor fails to find any devices.

File: /venvs/apps_venv/lib/python3.12/site-packages/reachy_mini/media/audio_gstreamer.py

Line ~470 — find:

            self.logger.warning(f"No {device_type} audio card found.")
Enter fullscreen mode Exit fullscreen mode

Replace with:

            self.logger.warning(f"No {device_type} audio card found via DeviceMonitor, falling back to ALSA hw:0")
            return "hw:0"
Enter fullscreen mode Exit fullscreen mode

This tells the SDK to use the first ALSA hardware device directly when the GStreamer DeviceMonitor can't enumerate devices. Since the Reachy Mini Audio board is always card 0, hw:0 is the correct device identifier.

Step-by-Step

  1. SSH into your Reachy Mini: 
   ssh pollen@reachy-mini.local
   # Password: root
Enter fullscreen mode Exit fullscreen mode
  1. Back up the original file: 
   cp /venvs/apps_venv/lib/python3.12/site-packages/reachy_mini/media/audio_gstreamer.py \
      /venvs/apps_venv/lib/python3.12/site-packages/reachy_mini/media/audio_gstreamer.py.bak
Enter fullscreen mode Exit fullscreen mode
  1. Edit the file: 
   nano /venvs/apps_venv/lib/python3.12/site-packages/reachy_mini/media/audio_gstreamer.py
Enter fullscreen mode Exit fullscreen mode

Jump to line 470 (Ctrl+Shift+_, type 470, Enter). Replace the warning line as shown above.

  1. Save (Ctrl+O, Enter) and exit (Ctrl+X).

  2. Restart the daemon and conversation app:

   sudo systemctl restart reachy-mini-daemon.service
   sleep 10
   reachy-mini-conversation-app --gradio --verbose
Enter fullscreen mode Exit fullscreen mode
  1. Verify the logs now show: 
   No Source audio card found via DeviceMonitor, falling back to ALSA hw:0
   No Sink audio card found via DeviceMonitor, falling back to ALSA hw:0
Enter fullscreen mode Exit fullscreen mode

Instead of the previous dead-end warning, the app now has a valid audio device and can send/receive audio through the OpenAI Realtime API.

How to Tell If You Have This Bug

You likely have this issue if all of the following are true:

  • Your Reachy Mini is the Wireless version (RPi-based, onboard compute)
  • The conversation app connects to OpenAI successfully (you see "Realtime session updated successfully" in the logs)
  • The robot moves, dances, and plays emotions on its own but never speaks or responds to voice
  • Running arecord -l shows the "Reachy Mini Audio" device
  • Running pactl returns "command not found" (no PulseAudio)
  • Running systemctl --user status pipewire returns "not found" (no PipeWire)

Notes

  • This patch assumes the Reachy Mini Audio board is always ALSA card 0 (hw:0). If you have additional USB audio devices connected, the card number may differ — check with cat /proc/asound/cards.
  • The fix is applied to the installed Python package and will be overwritten by SDK updates. After updating the Reachy Mini SDK, you may need to reapply the patch.
  • A more robust upstream fix could install PipeWire as a lightweight audio server, or modify the SDK's fallback logic to query ALSA directly when the DeviceMonitor returns no devices.
  • Consider opening an issue on the reachy_mini GitHub repository referencing this workaround so it can be addressed in a future release.

Environment

  • Robot: Reachy Mini Wireless
  • OS: Debian 13 (Trixie) on Raspberry Pi 4
  • Audio hardware: Pollen Robotics Reachy Mini Audio (XVF3800-based USB audio)
  • Audio stack: Pure ALSA (no PipeWire, no PulseAudio)
  • SDK: reachy_mini (installed in /venvs/apps_venv/)
  • Conversation app: reachy_mini_conversation_app with OpenAI gpt-realtime