Hello Waveshare team,
I've been running voice and camera integration on a WAVEGO Pro (Raspberry Pi 5, Debian 13). Several of these findings apply to any WAVEGO variant using the same USB audio hardware, so I am posting here as well for visibility.
The full field-notes document covers behavior I could not find in any official material.
Paper: https://github.com/Christinedickson71-sys/wavego-pro-voice-field-notes
This is not a support request and not a bug report against the hardware. The unit performed well. Every issue I hit turned out to be a software default or a missing line of documentation — but each one is capable of convincing an owner their unit is defective when it is not. I'm offering these findings to you freely, MIT licensed, in case they're useful for your documentation or support materials.
The four findings
1. The bundled Jieli USB speaker requires one specific ALSA configuration
Reliable playback only at:
Device: hw:0,0 Format: S16_LE Rate: 48000 Hz Channels: 2 (stereo)
Other formats produce silence or distortion.
2. Playback volume initializes at 30% and does not persist across reboots
$ amixer -c 0 sget PCM
Limits: Playback 0 - 147
Front Left: Playback 44 [30%] [-20.16dB] [on]
To a user this reads as a weak or failing speaker. The fix is amixer -c 0 sset PCM 85% plus alsactl store, but there is no way to know that from the documentation.
3. Duplicated autostart entries cause ALSA capture contention that looks exactly like a dead microphone
I spent considerable time believing the platform had no capture device at all. It had one the whole time — two processes were contending for it.
Diagnostic: sudo fuser -v /dev/snd/*
4. rpicam-vid --codec h264 fails on Raspberry Pi 5
ERROR: *** Unable to find an appropriate H.264 codec ***
The Pi 5 removed the hardware H.264 encoder present on the Pi 4. Any Pi 4-era guide produces this error verbatim with no explanation. A working MJPEG to software-x264 pipeline is documented in the paper and measured at 0.15x realtime — so 720p15 video is entirely practical, just via a different path.
Also included
- Moonshine vs faster-whisper STT benchmark run on the unit itself
- Sample video and stills captured and encoded by the Pi 5, for independent inspection
- A measurement of encode cost vs scene motion (~53% bitrate increase with movement)
- Full reproduction commands
Offer
Use any of it, with or without attribution. I am happy to verify these findings on additional units, or expand coverage to other parts of the platform if that would help.
Thanks for building genuinely capable hardware — the ceiling on this platform is higher than the documentation suggests, which is exactly why I wrote this up.
Christine M. Dickson
christine.dickson71@yahoo.com
Hello Waveshare team,
I've been running voice and camera integration on a WAVEGO Pro (Raspberry Pi 5, Debian 13). Several of these findings apply to any WAVEGO variant using the same USB audio hardware, so I am posting here as well for visibility.
The full field-notes document covers behavior I could not find in any official material.
Paper: https://github.com/Christinedickson71-sys/wavego-pro-voice-field-notes
This is not a support request and not a bug report against the hardware. The unit performed well. Every issue I hit turned out to be a software default or a missing line of documentation — but each one is capable of convincing an owner their unit is defective when it is not. I'm offering these findings to you freely, MIT licensed, in case they're useful for your documentation or support materials.
The four findings
1. The bundled Jieli USB speaker requires one specific ALSA configuration
Reliable playback only at:
Other formats produce silence or distortion.
2. Playback volume initializes at 30% and does not persist across reboots
To a user this reads as a weak or failing speaker. The fix is
amixer -c 0 sset PCM 85%plusalsactl store, but there is no way to know that from the documentation.3. Duplicated autostart entries cause ALSA capture contention that looks exactly like a dead microphone
I spent considerable time believing the platform had no capture device at all. It had one the whole time — two processes were contending for it.
Diagnostic:
sudo fuser -v /dev/snd/*4.
rpicam-vid --codec h264fails on Raspberry Pi 5The Pi 5 removed the hardware H.264 encoder present on the Pi 4. Any Pi 4-era guide produces this error verbatim with no explanation. A working MJPEG to software-x264 pipeline is documented in the paper and measured at 0.15x realtime — so 720p15 video is entirely practical, just via a different path.
Also included
Offer
Use any of it, with or without attribution. I am happy to verify these findings on additional units, or expand coverage to other parts of the platform if that would help.
Thanks for building genuinely capable hardware — the ceiling on this platform is higher than the documentation suggests, which is exactly why I wrote this up.
Christine M. Dickson
christine.dickson71@yahoo.com