2adde3a8b5
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
62 lines
3.5 KiB
Plaintext
62 lines
3.5 KiB
Plaintext
# 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.
|