# 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.
