9 Commits

Include renames

Author	SHA1	Message	Date
enricobuehlerandClaude Opus 5	a12f1f092c	feat(clients/audio): one de-jitter policy for all four rings, and lossless single-packet recovery ... Phase 4 + WP3.2 of design/audio-quality-and-latency.md. **The defect.** Every client ring primed *up* to a target and clamped at a ceiling, and none walked the depth back *down*. Any transient — a Wi-Fi arrival burst, a host stall, or plain host-DAC-vs-client-DAC skew of a few dozen ppm — therefore added latency permanently, until an underrun happened to re-prime. Android, with no shed at all, converged on its 120 ms hard cap and stayed there for the rest of the session; that is the "audio latency is too high" report. Apple did shed, 40 ms in one go, which its own comment called "one audible blip". All four now share `punktfunk_core::audio::JitterPolicy`: depths in MILLISECONDS rather than device quanta (`3 x quantum` meant 15 ms at a 5 ms quantum and a silent 64 ms at a 20 ms one), a crossfaded 5 ms shed once the depth average has sat above target for 2 s of consumed audio, and de-prime hysteresis. Linux and Windows had never had that hysteresis — they still carried the `if ring.is_empty()` instant re-prime that Android identified as self-inflicted crackle, where one transient drain manufactured a whole target's worth of silence. Android's floor drops 40 -> 25 ms: the policy grows the target on the devices that actually underrun, instead of every device pre-paying for the worst one. The Windows ring moves from raw bytes to interleaved f32 so it can share the policy and the crossfade helper at all. Apple is the one client where the policy is hand-written in a second language, so it gets its own XCTest (`AudioRingDriftTests`). Verified here by compiling `AudioRing.swift` standalone against a simulation harness — +200 ppm for 5 minutes settles at 30 ms with zero silent callbacks, where the old ring would have ridden its 80 ms high-water mark. **WP3.2 — recovery lives in core, not in the clients.** The rebuilt frame is re-inserted into the demux queue in order, so every embedder (including any C-ABI consumer) gets a complete stream without knowing the `0xD2` plane exists, and their `AudioGapTracker` simply stops seeing the gap. `recovery_and_the_gap_tracker_agree` pins exactly that. For the same reason core advertises CLIENT_CAP_AUDIO_RED itself rather than making four embedders remember to. Verified: clippy --all-targets -D warnings and the full test suites for punktfunk-core, pf-client-core, punktfunk-host, pf-host-config under Linux/docker (163 + 61 tests); punktfunk-client-android `cargo ndk check` for aarch64 with the gate proven non-vacuous by a planted type error, and its 6 clippy findings confirmed IDENTICAL to the pristine file (all are the documented arm64-only artifacts); AudioRing.swift type-checked and simulated on macOS; fmt. The Windows client half (audio_wasapi.rs) is still not compile-verified anywhere. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-04 09:28:01 +02:00
enricobuehlerandClaude Fable 5	6fbab53d56	feat(audio): libopus packet-loss concealment on the client audio plane ... The 0xC9 audio datagrams ride the lossy plane with no FEC, and no client ever consulted the per-packet sequence: a lost 5 ms Opus packet played out as a hard gap in the ring — an audible click/pop on every drop, i.e. constantly on the Wi-Fi links where video loss is already being FEC-absorbed. Now a shared `AudioGapTracker` (punktfunk-core::audio — pure data, wrap-safe, unit-tested incl. u32 wraparound / reorder / duplicate cases) tells the decoder how many packets went missing immediately before each received one, and both native clients (pf-client-core PipeWire path, Android AAudio path) synthesize that many frames of libopus packet-loss concealment first: `decode` with empty input (the opus crate maps it to a NULL data pointer = PLC), sized by the last real frame's sample count. Interpolated fade instead of a click. Bounds: a gap is capped at 10 packets (50 ms) — libopus PLC fades to silence after a few frames anyway, so past the cap the rings' existing underrun/re-prime path takes over. Reorders and duplicates conceal nothing (the plane has no reorder buffer; playing a late packet where it lands is the existing behaviour). In-band Opus FEC (LBRR) is deliberately NOT used: the host sends 5 ms frames and LBRR needs ≥10 ms frames to carry anything. The cap is a crate-private const so cbindgen keeps it out of the C ABI header. Host cargo tests + clippy green; android crate verified via cargo ndk check. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-10 14:55:37 +02:00
enricobuehlerandClaude Fable 5	da376b3122	fix(android): gate the latency overhaul behind an experimental toggle, default off ... The 5dc24a0 low-latency overhaul regressed badly on some phones. Every piece of it — decoder ranking, per-SoC vendor keys, the async decode loop, pipeline thread boosts, the ADPF max-performance bias, game-tagged AAudio, DSCP marking, the Wi-Fi low-latency lock, HDMI ALLM and the forced TV mode switch — now rides the "Low-latency mode (experimental)" toggle, default OFF. Off restores the pre-overhaul pipeline byte-for-byte: the sync poll loop, the platform-default decoder, and the original format keys (standard low-latency + blind Qualcomm twin + priority=0 + operating-rate=MAX together). - New pref key (low_latency_mode_experimental): the old key shipped default-ON, so any install that ever saved settings persisted true — flipping the default under the old key would leave exactly the regressed devices stuck on. - DSCP is applied at socket creation, so the toggle reaches the transport via NativeBridge.nativeSetLowLatencyMode → transport::set_dscp_default, called in the connect choke point before nativeConnect; the core DSCP default reverts to off everywhere. - nativeStartAudio(handle, lowLatencyMode) gates AAudio usage=Game. - VideoDecoders.pickDecoder now skips `.secure` decoder twins and decoders that require FEATURE_SecurePlayback: they need a secure surface, and a secure twin could out-score its plain sibling (only it advertising FEATURE_LowLatency), which black-screens a clear stream. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-06 20:18:59 +02:00
enricobuehlerandClaude Opus 4.8	5dc24a069f	perf(android): low-latency decode overhaul — vendor keys, async loop, system tuning ... Close the latency gap on the Android client with per-SoC decoder tuning, an event-driven decode loop, and full system integration. - Decoder selection: rank MediaCodecList decoders in Kotlin (hardware/vendor preferred, software avoided, FEATURE_LowLatency probed) and create the chosen one by name. Per-SoC low-latency keys gated on the codec-name prefix: Qualcomm picture-order + low-latency, Exynos (also Google Tensor), Amlogic, HiSilicon; MediaTek vdec-lowlatency set unconditionally. operating-rate = MAX (Qualcomm) vs priority = 0 (else) are mutually exclusive. NVIDIA/Rockchip/Realtek have no vendor key — covered by ranking + the standard low-latency key. - Async decode loop: AMediaCodec async-notify replaces the poll loop, presenting a decoded frame the instant it is ready instead of waiting out a poll interval. Behind USE_ASYNC_DECODE with the synchronous loop kept for A/B during bring-up. - System integration: Wi-Fi FULL_LOW_LATENCY lock and HDMI ALLM (setPreferMinimalPostProcessing) for the stream's lifetime; game_mode_config.xml opting out of OEM downscaling / FPS overrides. - Pipeline: boost the data-plane pump + audio thread priorities, AAudio usage=Game, DSCP marking on by default on Android, ADPF setPreferPowerEfficiency(false), and setFrameRateWithChangeStrategy(ALWAYS) to force the HDMI mode switch on TV. - lowLatencyMode master toggle (default on) as the escape hatch; the stats HUD now shows the resolved decoder name. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-06 07:25:16 +02:00
enricobuehlerandClaude Opus 4.8	495646b676	feat(client/android): Snapdragon latency tuning — ADPF pipeline hints, game mode, max-clock decode ... Three levers to lower and steady decode latency on Snapdragon (Adreno) devices: - ADPF (Adaptive Performance Framework): a new dlsym-resolved hint session (native/src/adpf.rs; API-33+, resolved at runtime so there's no build-time link dependency and libpunktfunk_android.so still loads on API 31/32) tells the CPU governor the video pipeline runs a per-frame real-time workload, so it keeps those threads on fast cores at high clocks. It now covers all three latency-critical threads — the pf-decode feed/drain/present loop, the core data-plane pump (UDP receive + FEC reassembly), and the audio thread — via a new generic hot-thread registry on NativeClient (register_hot_thread / hot_thread_ids; the pump self-registers). The session is built lazily on the first presented frame, since ADPF createSession rejects a set containing any not-yet-live tid. - operating-rate -> Short.MAX ("as fast as possible"): pushes the Qualcomm decoder to run each frame at max clocks instead of merely sustaining the display rate at a power-saving clock that adds per-frame decode latency. - appCategory="game": makes the app eligible for OEM Game Mode / Game Dashboard performance profiles. The core registry is cross-platform (gettid on Linux/Android, a no-op elsewhere) — no Android-specific pollution of the shared core. Host workspace + 64 core tests green; Android arm64-v8a + x86_64 (platform 31) build + clippy clean. On-device Snapdragon validation pending. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-03 17:16:11 +00:00
enricobuehlerandClaude Fable 5	c890de49c9	refactor(android): split session JNI into modules, HUD-gated stats, AAudio open retry ... - native: the 756-line session.rs becomes session/{mod,connect,input,planes}.rs around a SessionHandle (connect lifecycle + trust, input plane shims, plane start/stop + stats drain). - Decode-stats sampling is HUD-gated (nativeSetVideoStatsEnabled): with the overlay hidden the decode thread skips the per-AU clock read + lock; enabling resets the measurement window. - audio: the AAudio open path is a per-sharing-mode try_open closure — the realtime callback state (ring, prime, free-list) is rebuilt per attempt, so a failed exclusive-mode try can't leak state into the shared-mode retry. - Kotlin: ConnectScreen/StreamScreen slimmed by extracting ConnectDialogs, StatsOverlay and TouchInput. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-02 11:08:56 +02:00
enricobuehlerandClaude Opus 4.8	7612238a59	feat(audio): end-to-end 5.1/7.1 surround across the native path + all clients ... Adds negotiated 5.1/7.1 surround to the punktfunk/1 protocol and every client (previously stereo-only): - core: new shared `audio` layout table (LAYOUT_51/71 + identity multistream mapping, canonical wire order FL FR FC LFE RL RR SL SR); Hello/Welcome `audio_channels` negotiation via the trailing-byte back-compat pattern (old peers fall back to stereo); C-ABI `punktfunk_connect_ex6`, `punktfunk_connection_audio_channels`, and in-core multistream decode `punktfunk_connection_next_audio_pcm` for embedders without a multistream Opus decoder. Real-libopus channel-identity round-trip test. - host: native audio thread captures + Opus-(multi)stream-encodes at the negotiated count (with a cross-session cached-capturer channel-mismatch fix); GameStream surround unified onto the safe `opus::MSEncoder`, dropping `audiopus_sys` (~4 unsafe blocks) and un-gating Windows GameStream surround; WASAPI loopback capture relaxed to 2/6/8 with the correct dwChannelMask. - clients: Linux (PipeWire), Windows (WASAPI), Android (AAudio) decode via `opus::MSDecoder` + render multichannel; Apple decodes in-core to PCM → AVAudioEngine with an explicit wire-order channel layout; each gains a Stereo/5.1/7.1 setting. `punktfunk-probe --audio-channels N` is the headless validator. Verified on Linux: core/host/linux/probe test suites + the Android Rust (cargo-ndk) build, clippy -D warnings, and rustfmt all green. Windows/Apple builds, all on-glass checks, and the live native loopback are pending (CI / a free box). Also lands the concurrent in-tree HEVC 4:4:4 host work (PUNKTFUNK_444): it shares the same touched files (quic.rs, punktfunk1.rs, encode/*, ...) and so cannot be committed separately from the surround changes. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-06-28 21:11:05 +00:00
enricobuehlerandClaude Opus 4.8	24e566b201	fix(android/audio): kill the AAudio crackle (RT-safe ring + deeper buffer + XRun sizing) ... The jitter ring was a port of the Linux client's, but Linux runs on PipeWire (adaptive resampling masks host↔DAC drift + a shallow buffer); AAudio hands us a raw realtime callback and we own the buffer, so the same code crackled only on Android. Three converging causes, all fixed: - Heap free on the realtime audio thread every quantum (Android's Scudo free() has unbounded tail latency → XRun → click). Decoded buffers are now recycled back to the producer via a free-list instead of freed on the audio thread; the ring is pre-reserved so extend() never reallocates there. - The ring collapsed to ~15 ms on the tiny LowLatency burst and re-primed (a fresh silence) on every single empty callback. Now ~40 ms prime / ~150 ms hard cap, decoupled from the burst size, with de-prime hysteresis (re-prime only after a sustained drain). - AAudio's anti-glitch knobs were unused: prime the HW buffer above its 2-burst default and grow it on getXRunCount(). The post-open log now reports perf/sharing/buffer so a fall to a resampled legacy path is visible. Steady-state audio latency ~15 → ~40 ms (within lip-sync tolerance; matches the Moonlight/Sunshine operating point). cargo-ndk build both ABIs + fmt + clippy green. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-27 11:33:51 +00:00
enricobuehlerandClaude Opus 4.8	2f2147b093	refactor: drop milestone names + consolidate clients; loss-recovery & rumble fixes ... Two bodies of work in one commit (the rename moved files the fixes also touched). Naming/structure cleanup (pre-launch): - Host modules m3.rs->punktfunk1.rs, m0.rs->spike.rs; CLI m3-host->punktfunk1-host, m0->spike; bare `punktfunk-host` now prints help. Types M3Options/M3Source-> Punktfunk1Options/Punktfunk1Source. - Clients consolidated out of crates/ into clients/: punktfunk-client-rs-> clients/probe (crate punktfunk-probe), client-linux->clients/linux, client-windows->clients/windows, punktfunk-android->clients/android/native (crate punktfunk-client-android; kept [lib] name=punktfunk_android so the JNI contract is unchanged). crates/ now holds only core + host. - Milestone codes M0-M4 purged from code/CLI/CLAUDE.md/README/docs/docs-site, kept only in docs/implementation-plan.md. docs/m2-plan.md-> docs/gamestream-host-plan.md. CI/gradle/flatpak paths updated. Client loss-recovery (video froze and never recovered after a brief drop): - Export punktfunk_connection_frames_dropped through the C ABI (the core already tracked it for the client keyframe-recovery loop; it was never reachable from the ABI clients). Regenerated punktfunk_core.h. - Apple (StreamPump + Stage2Pipeline) and Android (decode.rs) now poll frames_dropped and request a keyframe when it climbs -- the same loss-driven recovery Linux/Windows already had. Under infinite GOP the decoder silently conceals reference-missing frames, so the decode-error trigger rarely fires. Apple rumble robustness (worked then went spotty -- DualSense + Xbox): - Add CHHapticEngine stopped/reset handlers (rebuild on app background / audio interruption / server reset) and drop the permanent `broken` latch on a transient drive failure; latch only when the controller truly has no haptics. - Surface swallowed SDL set_rumble errors on Linux/Windows + diagnostic logging. Verified: cargo build/clippy/fmt --workspace, C-ABI harness, header drift. Not runnable on this box (verify in CI): Gitea workflows, gradle/Android, flatpak, Swift/decky. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-18 21:05:58 +00:00