From 5d3afc526da25358457cc36029d1531e3b65fd43 Mon Sep 17 00:00:00 2001 From: sylph-decoder Date: Sat, 29 Aug 2026 16:49:17 +0000 Subject: [PATCH] re: the ALSA tee measured on Canary -- faithful now, but the guest still pads 150 s boot with --apu=alsa --mute=false, tee in front of the paced pulse slave. PulseAudio monitor, default 5.3 ms 39.3 percent silence 30.5 gaps/s PulseAudio monitor, 200 ms 15.6 percent silence 3.5 gaps/s PulseAudio monitor, 500 ms 50.1 percent silence 1.3 gaps/s ALSA tee to paced pulse slave 9.98 percent silence 8.37 gaps/s 106.2 s captured over about 151 s of wall clock, i.e. 0.70x real time: the file is SHORT rather than gap-riddled, which is the intended trade. Six distinct channels, no duplicates, sensible peaks. A format trap worth recording: xenia s ALSA driver is SND_PCM_FORMAT_FLOAT_LE and its log confirms 6 channels, so the raw tee is float32 and not s16. Reading it as s16 yields a plausible-looking file whose giveaway is peaks alternating exactly -0.00 / -4.82 across channels -- the two halves of each float landing in alternate channels. I measured it wrongly that way first. The residual 10 percent silence is not removed, but its meaning has changed. It is no longer invented by PulseAudio s monitor; the tee records exactly what Xenia wrote, and Xenia wrote silence, because its writer thread pads whenever the guest has not filled the ring. So the capture is faithful -- every sample in it is a sample the emulator emitted -- while the emulator is still padding, because the guest runs at about 0.7x real time here. No capture method can remove that. So this is a 3.9x improvement in silence and a change of attribution, not a clean capture. At 9.98 percent and 8.37 gaps/s it sits right on the port s fail bar, and should not be treated as an oracle without saying which side of the line it fell on. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd --- docs/re/audio-capture-alsa-file-tee.md | 37 ++++++++++++++++++++++++++ 1 file changed, 37 insertions(+) diff --git a/docs/re/audio-capture-alsa-file-tee.md b/docs/re/audio-capture-alsa-file-tee.md index 4ddfb2a4..f41ef21a 100644 --- a/docs/re/audio-capture-alsa-file-tee.md +++ b/docs/re/audio-capture-alsa-file-tee.md @@ -94,6 +94,43 @@ ffmpeg -f s16le -ar 48000 -ac 6 -i capture.raw out.wav `--apu=nop` stalls the guest in the intro movie still stands and is why `--mute=true` was there; it says nothing about the ALSA backend. +## ✅ Measured on Canary — and the residual silence changes meaning + +150 s boot, `--apu=alsa --mute=false`, tee in front of the paced pulse slave. +⚠️ **Xenia's ALSA driver is `SND_PCM_FORMAT_FLOAT_LE`** (`alsa_audio_driver.cc:173`) +and its log confirms `ALSA initialized: 48000 Hz, 6 channels (output: 6), +period: 512, buffer: 2048`. The raw tee is therefore **float32, 6 channels** — +reading it as `s16` produces a plausible-looking file with a giveaway signature: +peaks alternating exactly `−0.00 / −4.82 / −0.00 / −4.82 / −0.00 / −4.82`, which +is the two halves of each float landing in alternate "channels". + +| capture route | silence | gaps/s | notes | +|---|---|---|---| +| PulseAudio monitor, xenia default (~5.3 ms) | 39.3 % | 30.5 | | +| PulseAudio monitor, `PULSE_LATENCY_MSEC=200` | 15.6 % | 3.5 | | +| PulseAudio monitor, `PULSE_LATENCY_MSEC=500` | 50.1 % | 1.3 | | +| **ALSA tee → paced pulse slave** | **9.98 %** | 8.37 | 106.2 s captured over ~151 s wall = **0.70× real time** | + +**The file is short rather than gap-riddled, which is the intended trade** — and +six distinct channels, no duplicates, sensible peaks (−4.41 / −3.96 / −4.41 / +−11.65 / −8.09 / −6.53 dBFS). + +🔴 **But the residual ~10 % silence is NOT removed, and its meaning has changed.** +It is no longer invented by PulseAudio's monitor — the tee records exactly what +Xenia wrote, and **Xenia wrote silence**, because its writer thread pads whenever +the guest has not filled the ring (`alsa_audio_driver.cc:359`). So: + +* ✅ the capture is now **faithful** — every sample in it is a sample the + emulator emitted; +* ❔ the emulator is still emitting padding, because the guest runs at ~0.7× real + time here, and **no capture method can remove that**. Fixing it needs the guest + to keep up, or a change to the driver's padding behaviour. + +⚠️ **So this is a 3.9× improvement in silence and a change of attribution, not a +clean capture.** At 9.98 % / 8.37 gaps/s it sits right on the port's "≥10 % +silent *and* ≥1 gap/s" fail bar. **Do not treat it as an oracle without saying +which side of that line it fell on.** + ## Consequences for verification 🔴 **Short file becomes the failure mode**, so a capture check needs an