[USB/Lite] Microphone input returns all-zero audio on Linux (Jetson)

[BiboyLin]

Description

On Linux (NVIDIA Jetson), the Reachy Mini Lite USB Audio device microphone input returns complete silence (all-zero samples).

Environment

• Hardware: Reachy Mini Lite (USB)
• OS: Linux (NVIDIA Jetson Orin Nano, Ubuntu 22.04)
• SDK Version: reachy_mini 1.3.1
• Daemon Version: 1.3.1
• Audio Firmware: XMOS XVF3800 v2.1.2 (ua-io16-lin)

Steps to Reproduce

1. Connect Reachy Mini Lite via USB to Jetson
2. Start daemon: reachy-mini-daemon --headless --no-localhost-only
3. Run:

from reachy_mini import ReachyMini
r = ReachyMini(connection_mode=localhost_only)
r.media.start_recording()
samples = r.media.get_audio_sample()
print(f"Max: {abs(samples).max()}")

Expected

Non-zero audio values

Actual

Sample shape: (31872, 2)
Max: 0.000000
Mean: 0.000000

Diagnostic

• USB: 38fb:1001 (Reachy Mini Audio)
• USB endpoints: Has IN endpoint 0x81 (microphone input)
• ALSA capture: Enabled at 100%
• Firmware: v2.1.2

Questions

1. Is firmware v2.1.3 required to fix this?
2. Is this the same root cause as Microphone not working on Windows - 0% input volume (Beta Unit) #838 and [USB/Lite] Microphone input returns all-zero audio on macOS 26 (Tahoe) #820?

Related Issues

• Microphone not working on Windows - 0% input volume (Beta Unit) #838: Microphone not working on Windows - 0% input volume (Beta Unit)
• [USB/Lite] Microphone input returns all-zero audio on macOS 26 (Tahoe) #820: [USB/Lite] Microphone input returns all-zero audio on macOS 26 (Tahoe)

[BiboyLin]

Hi team! Just checking in on this issue - any update or workaround? We are seeing the same problem on Jetson Orin Nano. Thanks! 🧿

[brainwavecoder9]

I was able to get things going with a Lite on a Jetson Orin Nano. I vaguely remember some troubleshooting steps, I'll check my notes to see if I can identify anything.

That said, you do need the newer version of the XMOS firmware. I think it's as simple as running:
https://github.com/pollen-robotics/reachy_mini/tree/main/src/reachy_mini/assets/firmware/update.sh

[y-tor]

Same issue here on Pi5 with firmware v2.1.3 already installed (confirmed via dfu-util -l, ver=0213).

Audio works fine after boot, but after ~12-20h of continuous uptime, arecord returns all-zero audio (rms=0). HID routing fix (AUDIO_MGR_OP_L cat=3 src=0) and restarting arecord have no effect. Only a full Pi reboot restores audio.

So the firmware update to v2.1.3 doesn't fully fix the issue — there seems to be a long-uptime stability problem.

[CarolinePascal]

Hi everyone !

This issue seems related to the fix implemented in this PR : #852. Could try upgrading to the latest v1.5.0 and see if the issue persists ? Thanks !

Best,

Caroline.

[FabienDanieau]

1.5.1 also fixes a specific issue with linux

[felixleopold]

Ran into this on a Pi 4B (Raspberry Pi OS Lite 64-bit, PulseAudio) with the Reachy Mini Lite — same symptom: ALSA capture shows Running, mixers at 100%, format correct (S16_LE 2ch 16 kHz), but every sample is zero regardless of how loudly I talk.

Important distinction from the Pi5 report above: our mic is all-zero from the very first second after a cold boot — it never works at all. Not a long-uptime degradation issue. Different failure mode, same symptom.

Things I tried that did NOT fix it:

• alsamixer / amixer (already at full gain)
• pactl suspend-source toggle
• USB re-enumerate (authorized 0→1)
• usbreset
• modprobe -r / modprobe snd_usb_audio
• Disabling USB autosuspend
• Full Pi reboot
• Flashing firmware 2.1.3 (bundled in the SDK — dfu-util -d 38fb:1001 -R -e -a 1 -D reachymini_ua_io16_lin_v2.1.3.bin) + cold boot — no change
• Reading/writing XVF3800 control params via audio_control_utils — all nominal (mic gain 90, SHF_BYPASS=0, I2S_INACTIVE=0, output mux at firmware default)
• Setting AUDIO_MGR_OP_L / AUDIO_MGR_OP_R to cat=3 src=0 (the "HID routing fix" mentioned in the Pi5 report) — no change, still all-zero
• Capturing explicitly from the correct PulseAudio source (not the default)
• Opening a duplex stream (playing to the speaker sink simultaneously while recording)

The mic works fine tethered directly to a Mac (CoreAudio), so it's not hardware. Firmware 2.1.3 changelog mentions it "fixes initialization on beta units" — but no change on this Lite unit, so the bug appears to be deeper than what firmware ≤ 2.1.3 or host-side config can reach.

Any updates on this? Is there a newer firmware or a known workaround for the Lite on Linux? Thanks

[antigenius0910]

Adding an independent reproduction on a different platform, which suggests this is device/firmware-level rather than OS- or SDK-version-specific.

Environment

• Robot: Reachy Mini Lite (USB), audio device 38fb:1001 (Pollen Robotics Reachy Mini Audio)
• Host: x86_64 desktop, Ubuntu (kernel 6.17), PipeWire/PulseAudio
• SDK/daemon: 1.8.1
• USB descriptor reports the input terminal as 0x0405 Echo-canceling speakerphone (XMOS XVF3800), plus HID + vendor "Audio Control" + DFU interfaces

Symptom — identical to this issue: capture is exactly zero (peak 0.000000, rms 0.000000), while playback (speaker) on the same USB device works fine.

What I verified — the silence is below the SDK and below PipeWire; it's at the raw ALSA layer:

• SDK media_backend="local" → records a valid 5 s WAV, all samples 0
• parecord from alsa_input.usb-…Reachy_Mini_Audio…analog-stereo, with the daemon running and fully stopped → all 0
• arecord -D hw:Audio,0 -f S16_LE -c2 -r16000 (native params, bypassing PipeWire) → all 0
• ALSA mixer: Headset Capture Switch on, capture volume 100%, source unmuted; /api/state/doa returns {"angle":0.0,"speech_detected":false}

So on this unit the XVF3800 capture endpoint enumerates and negotiates format correctly but never emits non-zero audio.

This reproduces the same all-zero behavior reported here on Jetson/SDK 1.3.1, and on macOS (#820) / Windows (#838) — consistent with a firmware-level issue in the XVF3800 audio path rather than anything host-specific. Happy to provide full lsusb -v, amixer dumps, or run any diagnostic that would help.

[antigenius0910]

Independent reproduction on macOS 26 / Intel, which directly corroborates #820 and — together with the Linux and Windows reports here — points to the XVF3800 audio path itself rather than anything host-, OS-, or SDK-version-specific.

Environment

• Robot: Reachy Mini Lite (USB), audio device 38fb:1001 (Pollen Robotics Reachy Mini Audio), CoreAudio unique-id AppleUSBAudioEngine:Pollen Robotics:Reachy Mini Audio:…:1,2
• Host: Intel x86_64 MacBook Pro (i7-9750H), macOS 26.4.1 (Tahoe, build 25E253)
• SDK/daemon: 1.8.1
• Audio firmware: XMOS XVF3800 v2.1.2

Symptom — identical to this issue: capture is exactly zero (level meter floored at the S16 silence floor, every sample 0), while playback on the same USB device works fine. Note this is on macOS 26 — so the "mic works fine tethered to a Mac" workaround mentioned earlier does not hold on Tahoe; it matches #820 instead.

What I verified — the silence is below the SDK, below GStreamer/CoreAudio, and the device's own DSP confirms no mic signal:

• Daemon selects the correct device and capture path (osxaudiosrc, CoreAudio unique-id) with no errors.
• Capture is all-zero on both channels, at native S16LE/2ch/16k and resampled, with the daemon running and fully stopped (rules out a two-readers/device-busy confound).
• The built-in MacBook mic captures real audio (~-41 dB) through the exact same osxaudiosrc/GStreamer process → rules out CoreAudio, GStreamer, and macOS Microphone (TCC) permission as the cause.
• XVF3800 control plane is fully healthy: VERSION = 2.1.2, AUDIO_MGR_MIC_GAIN = 90.
• On-device DoA stays frozen (angle 0.0, speech_detected false) even while the USB IN endpoint is actively streaming and I make noise around the robot. DoA is computed on-chip, independent of the host OS — so a dead-flat DoA + all-zero audio while the control link is healthy localizes the fault to the XVF3800 capture/DSP path, not the host.
• No daemon code writes any XVF3800 mic-enable/unmute register at startup on any platform, and the built-in mic works — so this isn't a host-side init gap.

Firmware note: this unit is on v2.1.2 (I have not yet flashed v2.1.3). Given the reports above that v2.1.3 doesn't fully fix the Lite, this seems below the firmware layer. Happy to provide lsusb -v, full audio_control_utils register dumps, or run any diagnostic that would help isolate it.

[antigenius0910]

Update / correction to my report above: on my unit this turned out to be a hardware assembly issue, not the firmware bug — the microphone ribbon cable was installed upside-down. After reseating it correctly (per Pollen's assembly guide: blue side / "Main Board" text facing up), the mic works fully: capture went from all-zero (-350 dB) to live audio (~-10 dB), and the XVF3800's on-device DoA now tracks voice (angle sweeping ~80–100°, speech_detected=1) instead of being frozen at 0.0.

Worth highlighting for anyone else triaging this: an upside-down mic cable produces the exact same signature as this firmware issue — healthy XVF3800 control plane (VERSION/MIC_GAIN readable), all-zero capture, and dead DoA. So I'd suggest checking the ribbon orientation first before suspecting firmware.

My earlier comment should be discounted as a firmware reproduction. The genuine Linux reports in this thread (correct cabling, all-zero across reboots and firmware flashes) still stand.

[FabienDanieau]

What about you @BiboyLin , is your problem fixed?
FYI we have a new audio firmware that may solve this issue: #1242