audio.sh fails 2 of 3 runs, on a tone heard as two #334

docs/checks/audio.sh fails intermittently on the Android 15 emulator. A steady tone comes back as two segments, so the check's expected pitches do not match.

Seen on fe42c5b, before #330–#333, and on the branch that became #331. That branch does not change the capture or its analysis.

Results

Run in turn on the mobium-test AVD (Android 15, headless), with an iPhone 17 Pro simulator booted and idle:

Two more runs on the branch before that: 1 fail, 1 pass. A run before those failed in mobium test.

What it says

The tone step plays 440 Hz for 2 s:

heard ['440 Hz 0.6-1.5s', '440 Hz 1.6-2.5s'], want [440.0]
FAIL: 440 Hz for 2 s:

Other runs split it elsewhere:

heard ['440 Hz 0.4-0.9s', '440 Hz 1.1-2.5s'], want [440.0]
heard ['440 Hz 0.4-1.7s', '440 Hz 1.8-2.5s'], want [440.0]
heard ['440 Hz 0.4-1.1s', '440 Hz 1.1-2.5s'], want [440.0]

The mobium test step fails the same way, in audio.test.json › the sequence is heard in order:

expected 440 Hz for 1.8–2.3s, then 880 Hz for 1.8–2.3s; heard 440 Hz for 0.3s (0.5–0.8s), then 440 Hz for 1.5s (1.0–2.5s), ...

Not known

The cause is not established. The split falls at a different point each run, and the pitch is right on both sides. Most gaps are 0.1–0.2 s. One shows no gap at the timeline's tenth-of-a-second resolution, so a dropout in the capture is a guess, not a finding.

Not measured: the same runs with the simulator shut down, a different AVD, or a windowed emulator. audio.sh passed in earlier sweeps, and no bisect has been done.

Possible directions

Keep the WAV from a failing run and see whether the samples have a gap. That separates audio missing from the capture from a segment split in the analysis (audio.Sounds already joins a run of short pieces, but these pieces are long). If samples are missing, the question is whether the emulator or the capture stream drops them.