# Is this container's AUDIO clock real time? -- 2026-08-30
#
# WHY: ui-keyframe-time-unit.md reads "the game presents at 27.6 fps" off frame
# counts over wall-clock windows on one container. A guest running ~92 % of real
# time produces the same numbers, and three trials sharing a container cannot
# separate the two. sylpheed-port raised the general form of this after finding
# their own box takes 146.6 s of wall clock for 137.44 s of media (+6.7 %) on a
# 720p Theora decode, and warned that cross-agent timing must go through media
# length rather than wall clock.
#
# THE REFERENCE, and it is media-derived, not wall-clock derived:
#   BGM_103's loop bounds are BIT offsets in the XMA decoder context
#   (menu-bgm-loop-fields-conflict.md), and each wave's duration follows from its
#   own declared byte rate on the disc, cross-checked against the decoded PCM
#   (4 211 729 frames / 48 000 Hz = 87.744 s, 0.007 % from the declared 87.75).
#
#  ctx  bits/s declared   cycle bits   media s   wall s   wall/media
#    0           353470   22,034,741     62.34    61.87       0.9925
#    1           358325   22,677,193     63.29    61.87       0.9776
#
# ⚠️ THE METHOD'S OWN ERROR BAR IS 1.5 %. The two stems are sample-synchronous and
# must have equal duration; the linear bits->seconds conversion gives 62.34 and
# 63.29, disagreeing by 1.5 %. That is the precision available here, and it is why
# menu-bgm-loop-fields-conflict.md refused this conversion for the loop question.
# It is good enough for THIS question, which is about a 8.5 % effect.
#
# ✅ RESULT: wall/media = 0.985 +- 0.015.
#    A uniform 8.5 % slowdown predicts 1.085. The measurement is 10 % away from
#    that AND ON THE OTHER SIDE OF 1.0 -- wall clock is if anything SHORTER than
#    media, not longer. A container running the whole guest slow is REFUTED.
#
# 🔴 WHAT THIS DOES **NOT** SETTLE, and it is the part that matters.
# This bounds the AUDIO clock. On a box with no GPU, audio can hold real time on
# a timer while RENDERING lags -- so it does not follow that the frame clock is
# real time, and every number the doubt was raised about (27.6 fps, the 8.5 %
# splash excess) is a FRAME-clock number.
#
# What it does establish is that the two clocks can be COMPARED: if the frame
# clock ran 8.5 % slow while audio did not, a UI animation's wall-clock period
# would exceed its declared period in a run whose audio rate is nominal. That is
# a single-capture measurement, and it is what frame_vs_audio_clock.py does.