logan
0a25bca128
The e2e job's red history is one measurement being wrong. ALSA's `null` plugin does not pace: measured in this exact image through beep and oto with the same speaker.Init arguments player.InitSpeaker uses, 3000 ms of audio is consumed in 2.96 ms — a thousand times too fast. So every track finished instantly, the position reset to zero, and three specs failed on a clock that never moved. It read as a flake because InitSpeaker succeeds either way, in ~3 ms either way. A PulseAudio null sink is timer-scheduled: the same 3000 ms takes 3762 ms, and 12 s takes 13.5 s — the overhead is a constant buffer drain, not a rate error. Verified under the private session bus and Xvfb dev-headless.sh runs the app in, with no system D-Bus and no kernel module, which is what makes it reachable from a container. The sink is a dependency with a rate, so it is now checked like one: a step plays three seconds and fails if they take under two. Without it the failure surfaces three steps later as "the elapsed clock is 19 s adrift", which reads as an app bug and cost two sessions of exactly that suspicion.