Repository navigation
Live validation: perceived A/V sync worse than accepted beta; measure monitor and display path #652
Description
Owner report during human validation on 2026-09-26: A/V sync is "way worse" than before the night's work. Direction cannot be reliably judged by eye/ear yet. Current full Windows Release dev build is main 550f908, joined to the usual nine-participant test meeting with raw media privilege granted; Engine On, GoXLR Game monitor playing.
Evidence so far:
scripts/validate-av-clap.mjs --seconds 24 --keep-artifacton the current native Release build: eight paired events, median video-minus-audio -21.6 ms (audio lags), 17.0 ms spread; recorded Program path passes the 50 ms gate. Artifact:native/build-dev/Recordings/CoreVideoPro/validate-av-clap/av-clap-20260926-021022/Program.mp4(local development artifact).- Live telemetry: monitor underruns 0; audio lost samples 0; nine Zoom participants; Program frames advancing.
- Monitor endpoint: Game (TC-HELICON GoXLR). The WASAPI adapter has a 200 ms shared-mode endpoint buffer plus ~60 ms ring target. Existing
docs/zoom-audio-spec.mdcalls for measuring this chain and aligning the Program display, but that measurement is not yet available.
Next: identify which display/output the owner compares, capture a real meeting clap in the affected live path, measure monitor output versus displayed Program and recorded Program, then A/B against the previously accepted beta db9e703. Do not infer that the record-path pass disproves the live report. Relates to #627 and #579 but this is a new live-regression report.
Activity
iamfatness commentedon Sep 26, 2026
Owner clarification (2026-09-26): the current nine-participant test meeting uses AI-generated video. It is not valid human lip-sync acceptance. Do not close this issue from the fake-engine clap gate or the generated meeting alone.
Human validation protocol: use at least one real remote participant with camera and microphone on; show their face in CoreVideo Program; make several visible hand claps while recording Program and monitoring the GoXLR. Compare (1) live Program vs CoreVideo monitor and (2) finalized recording; repeat after a scene Take and after a camera off/on or leave/rejoin. Record which picture/audio device is being judged, approximate offset and direction if discernible, build SHA, meeting duration, and support bundle. A second real participant helps distinguish one guest's Zoom path from a common monitor/display offset. If the live mismatch recurs, A/B against the previously accepted beta on the same device and meeting setup before changing timing code.
iamfatness commentedon Sep 26, 2026
#652 work is in PR #655: #655
Matched 24 s Release A/B at Program depth 2 measured Program texture publish, GoXLR Game WASAPI loopback, and recorded Program in each run. Beta
db9e703measured −242.1 ms live monitor skew and −19.2 ms recorded skew; current maind23dc9d5measured −239.3 ms and −17.3 ms. Negative means audio lags. The synthetic A/B does not reproduce a beta-to-current regression, but confirms a large live monitor delay masked by a passing file.The PR reduces the monitor endpoint/ring buffering. Final candidate: −46.2 ms live, −33.4 ms recorded, 0 monitor underruns, 0 audio lost samples over 24 s. The PR's first comment has commands, SHAs, artifact paths, spread, and frame conversions. Real-human acceptance and long-show drift on GoXLR remain to be checked; issue stays open for that validation.
#652: measure live display/monitor sync and reduce WASAPI latency (#655)
iamfatness commentedon Sep 26, 2026
PR #655 merged to main as 7d0d363; all CI checks passed. The GoXLR live monitor clap improved from -239.3 ms on current-main A/B to -46.2 ms with 0 monitor underruns and 0 audio lost samples over 24 s. Issue remains open for real-human meeting acceptance and a longer monitor drift run. The already-running operator app still uses its pre-merge binary until rebuilt and restarted.