From 4f77ab26d76962893698494e40c85d7861d9ca0e Mon Sep 17 00:00:00 2001 From: sylph-decoder Date: Sat, 29 Aug 2026 16:52:51 +0000 Subject: [PATCH] re: --gpu=null gives a clean audio capture -- 0.31 percent silence, 0.01 gaps/s The residual padding in the ALSA tee was the guest running at 0.70x real time, and the dominant load is llvmpipe software rendering -- which an audio capture does not need at all. PulseAudio monitor, xenia default 39.3 percent silence 30.5 gaps/s ALSA tee to paced slave, rendered 9.98 percent silence 8.37 gaps/s ALSA tee to paced slave, --gpu=null 0.31 percent silence 0.01 gaps/s One gap in 67.7 s. Six distinct channels, no duplicates, sensible peaks. For scale the port s genuine music bed control measures 1.1 percent silence at 3.3 gaps/s, so this capture is cleaner than their known-good reference. Control that the run is still comparable: ADV s three XMA contexts appear in the --gpu=null log, so the movie s voice is decoding exactly as in a rendered boot. That is also better provenance for an audio question than screenshots were, since it evidences the thing being recorded rather than what was on screen. Records the full working recipe. Caveat: --gpu=null means no video, so screen-based provenance is unavailable and it is only appropriate when the question is about audio. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd --- docs/re/audio-capture-alsa-file-tee.md | 39 ++++++++++++++++++++++++++ 1 file changed, 39 insertions(+) diff --git a/docs/re/audio-capture-alsa-file-tee.md b/docs/re/audio-capture-alsa-file-tee.md index f41ef21a..64842ef1 100644 --- a/docs/re/audio-capture-alsa-file-tee.md +++ b/docs/re/audio-capture-alsa-file-tee.md @@ -131,6 +131,45 @@ 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.** +## ✅ SOLVED — `--gpu=null` removes the residual, and the capture is clean + +The residual padding was the guest running at **0.70× real time**, and the +dominant load is **llvmpipe software rendering** — which an *audio* capture does +not need at all. + +| configuration | silence | gaps/s | +|---|---|---| +| PulseAudio monitor, xenia default | 39.3 % | 30.5 | +| ALSA tee → paced slave, rendered (llvmpipe) | 9.98 % | 8.37 | +| **ALSA tee → paced slave, `--gpu=null`** | **0.31 %** | **0.01** | + +**One gap in 67.7 s.** Six distinct channels, no duplicates, peaks −5.15 / −4.55 +/ −4.47 / −11.65 / −6.73 / −6.40 dBFS. For scale, the port's *genuine music bed* +control measures 1.1 % silence at 3.3 gaps/s — **this capture is cleaner than +their known-good reference.** + +✅ **Control that the run is still comparable:** `ADV`'s three XMA contexts +(1 294 336 / 1 118 208 / 1 171 456) appear in the `--gpu=null` log, so the +movie's voice is decoding exactly as in a rendered boot. That is also better +provenance for an *audio* question than screenshots were — it evidences the thing +being recorded rather than what was on screen. + +### The full working recipe + +```bash +MAP=front-left,front-right,front-center,lfe,rear-left,rear-right +pactl load-module module-null-sink sink_name=cap channels=6 channel_map=$MAP +# asound.conf: NO include; tee in front of a PACED slave +# pcm.!default { type file slave.pcm { type pulse } file "…" format raw } +ALSA_CONFIG_PATH=…/asound.conf PULSE_SINK=cap \ + run-canary --apu=alsa --mute=false --gpu=null … +ffmpeg -f f32le -ar 48000 -ac 6 -i capture.raw out.wav # float32, not s16 +``` + +⚠️ `--gpu=null` means **no video**, so screen-based provenance is unavailable — +use the XMA probe instead. And it is only appropriate when the question is about +audio; it changes what the guest is doing. + ## Consequences for verification 🔴 **Short file becomes the failure mode**, so a capture check needs an