Skip to content

Audio Path

Every centimeter of the audio path, from file to speaker and voice to network.

Two independent audio paths share one piece of hardware. Music and calls travel separate software stacks that converge on a single WM8960 codec on the Whisplay HAT — an off-the-shelf part of the V0 “Dawn” rig (From Prototype to Product) — knowing which path a sound takes is the first step of every audio debug, because music dead but calls fine (or vice versa) localizes the fault immediately; the paths only share the codec. Playback is local-first: mpv is the local-only playback engine, and streaming providers are not treated as active sources.

The music path: the media worker spawns and supervises mpv — no separate music daemon, no Mopidy, no GStreamer; mpv dies with its host. The worker does the library work (filesystem scanning, playlist discovery, recents, shuffle queues) and hands mpv file paths; it never decodes audio itself. mpv pushes property events over its IPC socket, which is how Now Playing stays current without polling.

The call path: the voip worker runs Liblinphone, which routes to the same ALSA codec directly.

The hardware: card 0 is the wm8960-soundcard (bcm2835 I²S), and everything routes there — out to speaker or headphone. HDMI audio exists on card 1 and is unused.

  • Volume is one app-facing value written to two places: the system mixer (via amixer) and mpv — the levels multiply, which is the first thing to check when audio is quiet. On the production image the active ALSA controls are Speaker, Headphone, and Playback.
  • Config lives in two files: the music config (library directory, mpv socket and binary, default volume) and the device hardware config (the ALSA device routes for media, communication, and voice audio).
  • Install contract: the Pi image needs mpv and alsa-utils; validation is deploy, watch the logs, and confirm mpv starts under app control and answers on its IPC socket.

Today: the Whisplay HAT’s speaker, microphone, and WM8960 codec on the Pi Zero 2W prototype, verified against the live device. Target: a product board with its own speaker, microphone, and codec choices — still to be decided. Fixed by intent: speaker plus microphone, and playback that keeps working with no internet. Open: acoustic tuning, hardware volume limiting, and the headphone question.

  • What loudness ceiling do we commit to for kids’ hearing, and is it enforced in hardware or software?
  • Does the product device offer any wired or wireless headphone path, or speaker-only?
  • What echo/noise handling does push-to-talk need for a child talking outdoors near traffic?
  • Who arbitrates the speaker when a call and music playback collide, and is that a hardware or runtime contract?