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

re: --gpu=null gives a clean audio capture -- 0.31 percent silence, 0.01 gaps/s

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

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

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