From ac6d21837326f8e3053e9b875f1d4dddc780f89b Mon Sep 17 00:00:00 2001 From: sylph-decoder Date: Sun, 30 Aug 2026 23:28:40 +0000 Subject: [PATCH] re: both routes to the frame clock are blocked, and my no-PulseAudio claim was wrong Route 1, the port's hardware-consumption reference: I wrote 'no /dev/snd, no ALSA and no PulseAudio'. The first two hold; the third is false -- I checked only /run/user/*/pulse and concluded absence from one path, while pactl reaches a server at /tmp/pulse-*. The route is still blocked, accurately: the only sink is a module-null-sink, which is software-timed, so there is no hardware rate here. Route 2, varying host load: void. The 60 Hz and 30 Hz captures disagree by 2.8x, so neither is a guest rate, and x11grab achieved 17.5 of 60 requested fps -- the capture path is itself starved and cannot sample a ~28 fps guest. Records the concurrency confound against my own practice: this session ran cargo builds alongside emulator boots at least twice, and the older fps and dwell figures cannot now be audited for it. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v --- docs/re/data/frame-clock-route-blocked.txt | 61 ++++++++++++++++++++++ 1 file changed, 61 insertions(+) create mode 100644 docs/re/data/frame-clock-route-blocked.txt diff --git a/docs/re/data/frame-clock-route-blocked.txt b/docs/re/data/frame-clock-route-blocked.txt new file mode 100644 index 00000000..b5afcf62 --- /dev/null +++ b/docs/re/data/frame-clock-route-blocked.txt @@ -0,0 +1,61 @@ +# Can the FRAME clock be measured against a reference the guest does not control? +# 2026-08-30. ❔ NOT HERE. Two routes tried, both blocked, and one of my own +# claims corrected along the way. +# +# THE QUESTION: ui-keyframe-time-unit.md's 27.6-28.8 fps and the 8.5 % splash +# excess are frame counts per wall-clock second in this container. The audio path +# is bounded at 0.985 +- 0.015 of real time (container-audio-clock.txt), so a +# uniform slowdown is refuted -- but those are FRAME numbers, and rendering can +# lag while audio does not. +# +################################################################################ +# ROUTE 1 -- sylpheed-port's: frames presented per AUDIO SAMPLE CONSUMED, against +# hardware that consumes at a fixed rate. BLOCKED, and my first reading of why +# was wrong. +# +# 🔴 I FIRST WROTE "no /dev/snd, no ALSA and no PulseAudio". The first two hold. +# THE THIRD IS FALSE: I checked only /run/user/*/pulse and concluded absence from +# one path. There IS a running PulseAudio server -- +# pactl info -> Server String: /tmp/pulse-fljtwXMaGIXu/native, protocol 35 +# ⚠️ An absence established from ONE search path is not an absence. +# +# ✅ The route is still blocked, but for the accurate reason. The server has +# exactly one sink: +# 1 cap module-null-sink.c s16le 6ch 48000Hz SUSPENDED +# A NULL SINK IS SOFTWARE-TIMED -- it is driven by a timer, not by a crystal +# consuming samples. So there is no hardware rate in this container to measure a +# frame rate against, which is the one property every instrument in this session +# has lacked. +# +################################################################################ +# ROUTE 2 -- vary the LOAD instead. A rate set by the GAME does not move with host +# load; a rate set by STARVATION does. VOID: the instrument failed its control. +# +# capture 60 fps, idle 525 grabbed, 5 distinct in 30.0s -> 0.17 fps +# capture 30 fps, idle 540 grabbed, 14 distinct in 30.0s -> 0.47 fps +# capture 60 fps, +4 busy cores 326 grabbed, 3 distinct in 30.1s -> 0.10 fps +# +# 🔴 CONTROL FAILED. The 60 Hz and 30 Hz captures must agree if both oversample +# the guest; they differ by 2.8x, so neither is a guest rate. And x11grab achieved +# only 525 grabs in 30 s -- 17.5 fps of the 60 requested -- so THE CAPTURE PATH IS +# ITSELF STARVED and cannot sample a ~28 fps guest at all. The "-40 % under load" +# line the run printed is a property of ffmpeg, not of the game; it is not +# reported as a result. +# +# ⚠️ Note what the distinct-frame counter assumed: that consecutive presented +# frames differ by >200 px on a settled title whose sweep leaves free-run. Five +# distinct frames in 30 s says that assumption failed too, and I did not control +# it separately. +# +################################################################################ +# ⚠️ AND THE CONFOUND THAT APPLIES TO MY OWN PRACTICE, raised by sylpheed-port +# after it cost them a third correction: they found a measurement confounded by a +# test suite THEY had started alongside the run being timed -- a 7-percentage-point +# swing, larger than most effects either of us reports. +# +# This session has done the same thing: `cargo run` builds and disc sweeps were +# executed while an emulator boot was in progress, at least twice. No timing +# PUBLISHED this session came from those runs, but the older fps and dwell figures +# predate this session and their concurrency cannot now be audited. So: +# * a timing taken here is only as good as the box was quiet, and +# * "what else was running" belongs beside "what can be skipped" in METHOD.