Audio regression: Discord voice and call recording pull from Icecast instead of PulseAudio #2

New Issue

2026-08-19T22:06:55-04:00

logan commented

2026-08-19 22:06:55 -04:00

Both Discord voice (discord_radio.py:114-116, via discord.FFmpegPCMAudio) and call recording (call_recorder.py:67-68) obtain audio by HTTP-GETing the Icecast stream.

Intended design: PulseAudio for Discord voice and call recording (low latency), with Icecast reserved for live listening in the frontend and eventually mobile. The PulseAudio infrastructure already exists — null sink drb_sink, the pulse_socket docker volume, PULSE_SERVER, system.pa, libpulse0, and Liquidsoap's output.pulseaudio — but no Python code reads from it.

The Icecast path adds buffering latency, which causes the start of a transmission to be missed. This is not a cosmetic issue: recording quality is the foundation of the whole pipeline. A recording that starts late poisons the transcript, which poisons entity and scene extraction, which poisons incident correlation. Everything downstream is hostage to it.

Both Discord voice (`discord_radio.py:114-116`, via `discord.FFmpegPCMAudio`) and call recording (`call_recorder.py:67-68`) obtain audio by HTTP-GETing the Icecast stream. **Intended design:** PulseAudio for Discord voice and call recording (low latency), with Icecast reserved for live listening in the frontend and eventually mobile. The PulseAudio infrastructure already exists — null sink `drb_sink`, the `pulse_socket` docker volume, `PULSE_SERVER`, `system.pa`, `libpulse0`, and Liquidsoap's `output.pulseaudio` — but no Python code reads from it. The Icecast path adds buffering latency, which causes the start of a transmission to be missed. This is not a cosmetic issue: recording quality is the foundation of the whole pipeline. A recording that starts late poisons the transcript, which poisons entity and scene extraction, which poisons incident correlation. Everything downstream is hostage to it.

logan commented

2026-08-20 03:04:53 -04:00

Already fixed in the code — this issue was filed from CLAUDE.md and memory rather than from source, and both were stale.

Both paths are on PulseAudio now:

discord_radio.py builds its discord.FFmpegPCMAudio with before_options="-f pulse" against settings.pulse_source (default drb_sink.monitor), and waits on pulse.wait_until_ready() before joining. Its own comment states Icecast is deliberately not used here.
call_recorder.py is a full rewrite: ONE persistent FFmpeg PulseAudio capture for the lifetime of the node, emitting raw s16le/22050/mono PCM. Two buffers — a 30s ring buffer whose only job is 0.25s of pre-roll, and a per-call accumulator so call length is bounded by MAX_RECORDING_SECONDS = 600 rather than by the ring. Silence detection is integer arithmetic on the raw PCM, MP3 encoding happens once at save.

That last part went further than this issue asked for: segmentation is now audio-driven rather than control-channel-driven (call_recorder.audio_activity() is polled by metadata_watcher), which is the actual fix for transmissions starting late. New supporting modules: internal/pulse.py, internal/pcm.py, internal/audio_trim.py.

CLAUDE.md's "Audio path (current vs intended)" section has been rewritten to describe what the code does, and the audio-architecture-regression memory has been deleted. Both were actively misleading.

Already fixed in the code — this issue was filed from CLAUDE.md and memory rather than from source, and both were stale. Both paths are on PulseAudio now: - `discord_radio.py` builds its `discord.FFmpegPCMAudio` with `before_options="-f pulse"` against `settings.pulse_source` (default `drb_sink.monitor`), and waits on `pulse.wait_until_ready()` before joining. Its own comment states Icecast is deliberately not used here. - `call_recorder.py` is a full rewrite: ONE persistent FFmpeg PulseAudio capture for the lifetime of the node, emitting raw s16le/22050/mono PCM. Two buffers — a 30s ring buffer whose only job is 0.25s of pre-roll, and a per-call accumulator so call length is bounded by `MAX_RECORDING_SECONDS = 600` rather than by the ring. Silence detection is integer arithmetic on the raw PCM, MP3 encoding happens once at save. That last part went further than this issue asked for: segmentation is now audio-driven rather than control-channel-driven (`call_recorder.audio_activity()` is polled by `metadata_watcher`), which is the actual fix for transmissions starting late. New supporting modules: `internal/pulse.py`, `internal/pcm.py`, `internal/audio_trim.py`. CLAUDE.md's "Audio path (current vs intended)" section has been rewritten to describe what the code does, and the `audio-architecture-regression` memory has been deleted. Both were actively misleading.

logan closed this issue

2026-08-20 03:04:53 -04:00

logan added the area/recording-audio

labels 2026-10-05 02:05:06 -04:00

Sign in to join this conversation.