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. |
||
|---|---|---|
| .. | ||
| headroom-cli | ||
| headroom-client | ||
| headroom-core | ||
| headroom-dsp | ||
| headroom-ipc | ||