attempt to fix mic audio streaming

2026-07-15 16:52:01 -04:00
parent e9719ff61e
commit 442daac518
1 changed files with 78 additions and 0 deletions
@@ -0,0 +1,78 @@
 ---
 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)