perf(discord): stream voice PCM to ffmpeg instead of a temp file

[FixItFoundry]

What

VoiceReceiver.pcm_to_wav staged every captured utterance in a NamedTemporaryFile purely to give ffmpeg an input path, then unlinked it. This pipes the PCM to ffmpeg's stdin instead.

Per voice utterance that removes one file created, written, read back and deleted — on a path that runs for every spoken message (adapter.py calls it via asyncio.to_thread on each utterance). The try/finally cleanup goes away with it, so the function gets shorter as well as faster.

Why the WAV still goes to a file, not stdout

The obvious next step — capture the WAV from stdout too — is a trap, and worth recording here.

ffmpeg cannot seek on a pipe, so it cannot go back and patch the RIFF/data chunk sizes after writing. A WAV produced with -f wav pipe:1 carries placeholder 0xFFFFFFFF sizes. Measured on a 1s 48kHz stereo clip:

output	RIFF size field	data size field	wave.getnframes()
pipe:1	4294967295	4294967295	2147483647
output_path	32070 (correct)	32000 (correct)	16000 (correct)

Any reader that trusts the header — which is the whole point of writing a WAV rather than raw PCM for STT — misjudges the length. So the input is piped and the output keeps its real, seekable path.

Tests

• test_pcm_is_piped_to_stdin_not_staged_on_disk — asserts the PCM goes over input=, that pipe:0 is used, that the final arg is the real output path, and that no .pcm temp file appears in the command.
• test_output_wav_header_reports_true_length — skipped when ffmpeg isn't installed; converts a real 1s tone and asserts the header reports 16000 frames rather than the piped-stdout placeholder.

Full tests/gateway/test_voice_command.py + test_discord_voice_mixer.py: 208 passed.

[teknium1]

Thanks for the focused per-utterance I/O reduction. The current-main premise is still present: pcm_to_wav stages PCM at plugins/platforms/discord/adapter.py:780, and it is invoked once per processed utterance at plugins/platforms/discord/adapter.py:4381.

Problems

• The new hard-coded "ffmpeg" executable (plugins/platforms/discord/adapter.py:723 in this diff) regresses current main's resolve_ffmpeg_executable() call at plugins/platforms/discord/adapter.py:788. That resolver was added in 9b89da23fb8d76a7c208168c57c3eb5bec891d60 to support FFMPEG_PATH and Windows winget installs outside PATH; current coverage asserts this conversion path at tests/gateway/test_voice_command.py:776.

Suggested changes

• Preserve resolve_ffmpeg_executable() as argv[0] while changing only the PCM input from a path to pipe:0 plus input=pcm_data.
• Update the pipe-input test to exercise the resolved executable as well.

Automated hermes-sweeper review.

[teknium1]

Please retain resolve_ffmpeg_executable() here rather than restoring the literal "ffmpeg". Current main uses the resolver for this conversion so Windows winget installs and FFMPEG_PATH work when ffmpeg is absent from PATH (9b89da23fb8d76a7c208168c57c3eb5bec891d60; tests/gateway/test_voice_command.py:776).

[kshitijk4poor]

Thanks @FixItFoundry — the stdin-piping optimization is exactly right (no temp-file lifecycle per utterance, WAV correctly still file-backed to avoid placeholder RIFF sizes) and your tests verify the real ffmpeg header. Salvaged into #76970 with your authorship preserved via cherry-pick; during conflict resolution the bare "ffmpeg" from your stale base was swapped back to main's resolve_ffmpeg_executable() (Windows winget discovery + FFMPEG_PATH override), and main's 3 newer tests were retained alongside yours. 158 voice-suite tests green. Closing in favor of the salvage.