fabi/Sylpheed
1
0
Fork 0
Code Issues 9 Pull Requests Actions Packages Projects Releases Wiki Activity

re: the ALSA tee measured on Canary -- faithful now, but the guest still pads

Browse Source 
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) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
This commit is contained in:
sylph-decoder
2026-08-29 16:49:17 +00:00
parent 12146ca11d
commit 5d3afc526d
1 changed files with 37 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

37
docs/re/audio-capture-alsa-file-tee.md
View File

@@ -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