---
title: "Volume display and audio underrun fixes"
tags: []
author: claude
count: 2
exporter: 3.1.0
date: 2026-07-15T19-21-17+0000
url: https://claude.ai/chat/0c44df5d-e4f0-425d-9730-53563dd8f762
---

# Volume display and audio underrun fixes

## Table of Contents

- [1: The wav file had distant sounds from my coworkers yapping. I didnt get…](#chat-1)
- [2: audio works but is too quiet, amplify it and mix it all to make it mon…](#chat-2)

## chat-1

> The wav file had distant sounds from my coworkers yapping. I didnt get to talk but that proves the mic does do something
> 
> ┌──(lucka㉿theuniverseismine)-[~/programming/py/naowalk] 
> └─$ python3 naomictest.py --ip spike.local --port 9561 
> [W] 1784142061.737086 18238 qi.path.sdklayout: No Application was created, trying to deduce paths 
> ✅ Connected to spike.local 
> 
> === TEST 1: Mic hardware energy (all 4 mics) === 
> Make noise near the robot's head (clap, talk right up close to it) for 10s... 
>  t=0s  front=1.86  rear=1.76  left=22.41  right=25.90 
>  t=1s  front=1.78  rear=1.66  left=10.84  right=12.57 
>  t=2s  front=1.77  rear=1.75  left=12.23  right=13.08 
>  t=3s  front=1.75  rear=1.73  left=18.84  right=19.08 
>  t=4s  front=1.69  rear=1.78  left=18.88  right=18.45 
>  t=5s  front=1.73  rear=1.75  left=17.76  right=19.11 
>  t=6s  front=1.71  rear=1.79  left=15.86  right=14.67 
>  t=7s  front=1.73  rear=1.84  left=20.97  right=21.05 
>  t=8s  front=1.83  rear=1.72  left=14.95  right=15.82 
>  t=9s  front=1.68  rear=1.78  left=10.71  right=12.04 
> ⚠ Flat mic(s): front, rear. The others responded normally, which points to a fault specific to front, rear rather than the audio 
> pipeline as a whole (that pipeline is clearly working for the others). 
> 
> === TEST 2: Local on-robot recording === 
> Recording 5s directly to /home/nao/mic_test.wav on the robot itself (this bypasses the network stream and your laptop's audio sta
> ck entirely)... 
> Done. Pull it off and play it with: 
>  scp nao@spike.local:/home/nao/mic_test.wav . 
>  (then open mic_test.wav in any media player - it's 4-channel, so check all channels) 
> If that file has clearly audible sound, the mic and robot are fine and the 
> bug is specifically in naowalk.py's live-streaming path. 
> 
> === TEST 3: Robot's own speaker === 
> Press Enter to have the robot say a test phrase out loud...hi 
> If you heard the robot speak just now, its speaker output is fine (this is unrelated to hearing its mic on your laptop, but rules
> out a robot-wide audio fault). 
> 
> Done. Report back which test(s) failed and we'll know exactly where to look.

That's the smoking gun. Look at the pattern: **left and right respond strongly to noise (10–25), front and rear are dead flat (~1.7–1.9)** — every single test agrees. And the recording that had audible coworker chatter makes total sense now: it's a 4-channel file, so the left/right tracks caught that audio while front/rear stayed silent.

This was never a bug in the code. `naowalk.py` was explicitly requesting the **front** mic (`setClientPreferences(..., 3, 0)` — channel 3 = FRONTCHANNEL), which happens to be one of the two dead mics on this robot. It was faithfully streaming from a mic that produces no signal.

Fix: point the stream at a working mic instead — left or right. Let me make it configurable so you can pick whichever sounds better:

Now add the CLI flag and pass it through:

Let's verify and ship it:

___
###### [top](#table-of-contents)
## chat-2

> audio works but is too quiet, amplify it and mix it all to make it mono

Now let's rewrite `SoundReceiver` to request all mics, mix down to mono skipping dead channels, and apply amplification with a soft limiter:

___
###### [top](#table-of-contents)