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) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v

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.