HydraIssues

See how ee can leverage pyrowave, replace moonshine / sun...
open unclassified Project: hydra Reporter: anonymous 25 Jun 2026 12:33

Description

See how we can leverage pyrowave, replace moonshine / sunshine codec?

https://github.com/Themaister/pyrowave


Update 2026-09-09 (Claude):

  • PyroWave: intra-only wavelet codec in Vulkan compute shaders, <0.2 ms encode/decode, needs 200+ Mbit/s. MIT. Valve ships it experimentally in Steam Remote Play.
  • WiVRn maintainer prototyped it: branch proto/pyrowave (27 commits, stale since 2025-09, 1008 commits behind).
  • Forked and ported onto current upstream: https://github.com/cederikdotcom/hydra-wivrn branch pyrowave. Server encoder + client GPU decoder rewritten against 2026 interfaces; CI build running. Runbook in docs/runbooks/runbook.md.
  • Target hardware: Quest 3 / 3S on a dedicated WiFi 6E AP. Quest 2 stays on H.265.
  • Next: build both sides, stream to a Quest 3, measure decode time + battery vs H.265 baseline.
  • Note: WiVRn is a separate stack from our Sunshine/Moonlight path (hydraheadquest). This proves the codec on Quest-class hardware; replacing the Sunshine/Moonlight codec is a separate effort.

Update 2026-09-10: CI fully green on the fork at commit 3576bbc3 (all server variants, Android Oculus/Release APKs, Ubuntu package, Nix, flatpak). The ten stale Monado feature patches were consolidated into one patch rebuilt against the pinned Monado revision. Ready for on-headset validation: install server + Quest APK, stream to a Quest 3 on a 6 GHz AP, measure decode time and battery vs H.265.

Update 2026-09-14: Omarchy (quattro, 4.0.2) server validated on msi1060 (spicy-cactus-76, node-d71b197c, GTX 1060). Built from source via cluster exec, smoke test passed as the desktop user: pairing PIN issued, avahi-published as msi1060cederik, pyrowave forced in ~/.config/wivrn/config.json at 200 Mbit/s. contrib/arch/PKGBUILD + Omarchy runbook section added (commit 0f387166). Pascal note: no shaderFloat16, pyrowave uses non-fp16 shaders. Next: pair a Quest 3 and stream.

Update 2026-09-14 (later): validation experience staged on msi1060: hello_xr (Vulkan) built from OpenXR-SDK-Source, auto-launched via the WiVRn config application field. Sanity passed: hello_xr creates its OpenXR instance against the WiVRn runtime and waits for a headset session. Test content plan: hydragon (#615) is the intended test executable; its Linux cook is blocked on Epic Launcher sign-in on fluffy to add the UE Linux target component (UBT: missing files required to build Linux targets). hello_xr covers pyrowave stream validation until then.

MILESTONE 2026-09-14: PYROWAVE STREAMED TO A HEADSET. Quest 2 (org.meumeu.wivrn.github.testing 26.6-234-g3576bbc3) to msi1060. Server log: two encoders "pyrowave (pyrowave 8-bit)" 960x1024 at 99.98 Mbit/s each, alpha on vulkan h265. OpenXR session reached FOCUSED, hello_xr rendering, audio + mic streams up, hand interaction profiles negotiated. The port works end to end on real hardware.

Bugs found and fixed on the way:

  1. Server config key is "encoder" (singular), not "encoders". My config used the plural, which is silently ignored, so the first attempt streamed vulkan h265 at 24.6 Mbit/s instead of pyrowave. Unknown keys are dropped without warning.
  2. hello_xr exits immediately under systemd: its "press any key to shutdown" check sees stdin at EOF. Launch it as sleep infinity | exec hello_xr so stdin never closes. This was the "waiting for application" state.
  3. ufw on msi1060 denied incoming from the LAN (only 10.10.0.0/16 was allowed), so the headset could ping but never reach TCP 9757 or mDNS. Opened 9757 tcp+udp and 5353 udp scoped to 192.168.68.0/22.
  4. REAL PORT BUG, fixed in da044cab: the prototype's x50 pyrowave weight in split_bitrate starved the alpha stream. split_bitrate divides a fixed client-set budget by relative weight; both eyes are pyrowave so the x50 cancels between them and only crushes alpha, to 0.05 Mbit/s (555 bits per frame at 90 fps). The client then intermittently logs "Failed to find a common frame for all decoders" with the alpha decoder empty, and stalls. Weighting pyrowave like other codecs costs each eye 1.2 Mbit/s and gives alpha 2.47 Mbit/s.

NOTE: bitrate is a CLIENT setting; WiVRn has no server-side bitrate key. Set it in the headset app (200 Mbit/s used here).

Still open: msi1060 is on WiFi, not ethernet, so both ends share 5 GHz air. Quest 3/3S remains the intended target. No frame-time or battery measurement taken yet.

UPDATE 2026-09-14 (final): merged to the fork's master (e6a7db92) and the validation content is branded.

  • Historical issues filed: #726 (alpha starvation, fixed), #727 (compositor image not sampleable, the green screen, fixed), #728 (shader device features not enabled, OPEN), #729 (unknown config keys silently ignored), #730 (hello_xr stdin EOF).
  • Runbook now carries the validated config, the three config traps, and the debugging ladder that found #727: split the eyes between codecs, dump the bitstream and check its entropy, then Vulkan validation.
  • Test content is HelloHydra XR (hydrahelloxr v2.0.0), deployed on msi1060 and chunky.

FOLLOW-ON MASTER #734: "Linux bodies first-class, WiVRn as an XR driver alongside ALVR". PyroWave streams today only because a human runs systemd-run on msi1060; #734 is the route to a venue, with children #735-#740. Gating work first: #728 (device features) and the unmeasured encode/decode/battery comparison against H.265.

Sub-issues (5)

open #729 WiVRn server config: unknown keys are silently ignored
open #728 pyrowave: shader device features are not enabled on the compositor device
closed #727 pyrowave: compositor image was not sampleable, so the encoder read nothing
closed #726 pyrowave: x50 bitrate weight starved the alpha stream
closed #713 Make Khronos hello_xr a first-class ExperienceNet experience