The lossless audio plane stops being an operator opt-in — PUNKTFUNK_AUDIO_HIRES defaults on #280
Merged
enricobuehler
merged 1 commits from 2026-08-17 11:18:59 +00:00
worktree-audio-hires-default-on into main
1
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 enricobuehler
|
9a163d4ebf |
feat(host/audio)!: the lossless plane stops being an operator opt-in — PUNKTFUNK_AUDIO_HIRES defaults on
apple / swift (pull_request) Successful in 2m3s
apple / distribute (pull_request) Skipped
apple / screenshots (pull_request) Skipped
ci / web (pull_request) Successful in 2m8s
windows-client / client (x64, , x86_64-pc-windows-msvc, C:\t) (pull_request) Successful in 7m19s
ci / bun-nix (pull_request) Successful in 2m35s
ci / rust-arm64 (pull_request) Successful in 5m11s
windows-client / client (arm64, --no-default-features, aarch64-pc-windows-msvc, C:\t-a64) (pull_request) Successful in 3m9s
ci / docs-site (pull_request) Successful in 5m42s
android / android (pull_request) Successful in 7m6s
ci / rust (pull_request) Successful in 33m20s
A user picked "Lossless 96 kHz / 24-bit" in the macOS client, connected to a
bazzite host, and got Opus. Nothing in any UI said why; the reason was one INFO
line in the host's journal saying PUNKTFUNK_AUDIO_HIRES was not enabled.
So flip the host half: default ON, explicit-off grammar, `=0` to refuse. That
makes it the same shape as PUNKTFUNK_444, PUNKTFUNK_CHACHA20 and
PUNKTFUNK_10BIT, and the field stops being the one `Option<bool>` in
pf-host-config read as `unwrap_or(false)` — it is now a plain `bool`.
The old default rested on "this spends bandwidth the host's owner never agreed
to". Every clause of that is still true, but the operator is not who spends it —
the client's user is, and §8.4 condition 1 is already that user's explicit menu
choice, which still ships OFF. What was really being protected was nothing: the
conditions that keep a link safe are mechanical, not consent-based (the capture
path must honestly deliver the rate, the cost must fit a quarter of the
session's video bitrate, and a frame must fit a datagram). A 5 Mbps session
still cannot buy 96/24. The operator gate was not keeping modest links safe, it
was keeping the feature unreachable.
No wire or ABI movement: HOST_CAP_AUDIO_HIRES is set only when a session
actually resolved to PCM, so it stays a statement about that session's wire
rather than a capability advert, and an ordinary session (no
CLIENT_CAP_AUDIO_HIRES) is byte-identical to before.
Also:
- The decline log now names the opt-out and the value it must have, and tells
the operator to remove the line. The old wording sent people looking for
something to enable, which is now exactly backwards.
- The capture-rate probe's short-circuit guarantee ("an ordinary session must
not pay COM work for a feature nobody asked for") now rests on `hires_asked`
ALONE, so that condition has to stay first. Noted where it matters.
- The four Android comments warning that sending 48000/16 as a stand-in for
"default" silently opts users into PCM described the blast radius as "any host
with PUNKTFUNK_AUDIO_HIRES=1". That is now every host that has not
deliberately opted out, so those warnings are strengthened, not softened — the
0/0 sentinel is load-bearing in a way it was not before.
- The "must be asked for at BOTH ends" claim is corrected in the Apple, Android
and pf-client-core settings docs, and in the two docs-site surfaces. Those
rows also carried pre-flip staleness (48/96 kHz only, stereo only, 1.5-4.6
Mbps) that predates the 44.1 family and hi-res surround landing; the figures
are now 44.1-176.4 kHz, stereo through 7.1, 1.4-8.5 Mbps.
Gated on linux/amd64 (punktfunk-rust-ci): clippy --all-targets -D warnings
clean, punktfunk-host 597 passed / 0 failed, pf-host-config 14 passed / 0
failed, both crates verified non-vacuously compiled.
|