headroom/crates
atagen 4a80a16d79 docs: explain why mono streams aren't link-enforced
The `pair_count < 2` early-return in `apply_pending_routes` looked
arbitrary from the outside (and Codex+self-review both flagged it
as a possible bug). It's actually a deliberate choice: WP's
source-side upmix adapter handles mono → stereo cleanly today,
and broadcasting one source port to N target ports via link-factory
fanout requires the limiter's stereo-link semantics and the
BS.1770 multichannel weights to make sense for N=1 — neither
generalises trivially. The proper fix lives in the v1
multichannel pipeline.

Replaces the old "PipeWire's adapter is responsible for any
downmix" comment with the actual reasoning + the contract caveat
(`route.set` on a mono app won't move it; the metadata write is
a hint, not enforcement) so a future contributor doesn't
accidentally "fix" it without weighing the trade-offs.

No code change beyond the comment + the debug-log message.
2026-05-21 19:50:11 +10:00
..
headroom-cli 8e: playback callback timing instrumentation + spike investigation 2026-05-21 16:42:46 +10:00
headroom-client stage 2 2026-05-19 16:33:09 +10:00
headroom-core docs: explain why mono streams aren't link-enforced 2026-05-21 19:50:11 +10:00
headroom-dsp fix: close audio-gap on unchanged ReevaluateAll; reset compressor on enable 2026-05-21 19:42:12 +10:00
headroom-ipc 5: monitor TUI + wire fill-ins 2026-05-21 13:35:27 +10:00