[Bug] Voice output crackles even when decoded RTP PCM bypasses the Codex helper

Summary

Codex CLI Voice output crackles on WSL2/Linux even when the local Codex playback helper is bypassed. The exact decoded RTP PCM, played directly through PulseAudio, still crackles on the speaker.

Environment

• Codex CLI 0.155.0; also reproduced with a local 0.156.0-alpha.2 helper runtime
• Linux under WSL2, PulseAudio RDPSink speaker output
• Realtime Voice output through the Codex voice helper

Reproduction

1. Start a Codex Voice session and request continuous test speech.
2. Capture received RTP packets and decode them to PCM.
3. Play that decoded PCM directly with paplay, bypassing the Codex helper.
4. Listen on the same speaker output.

Actual behavior

The direct PCM playback still crackles. It is therefore not caused by Codex's CPAL device queue or its GStreamer-to-speaker handoff.

Diagnostics

• RTP sequence numbers were continuous: no packet loss.
• A fixed-cadence offline Opus decode, the live GStreamer decode, and the PulseAudio monitor capture all contained the same nine short near-silent intervals (3–54 ms) in one controlled speech run.
• The live decoded PCM and PulseAudio monitor capture correlated at 0.999999 or higher after the fixed output latency was aligned.
• A continuous local 440 Hz tone through ALSA -> PulseAudio -> RDPSink had no 3–60 ms silent runs and no large waveform jumps.
• Direct playback of the decoded RTP PCM still produced audible crackle.

This points to a defect already present in the received/generated RTP audio, or a downstream speaker path response to those short intervals. A local fade/declick experiment did not remove the audible artifact.

Expected behavior

Realtime Voice output should be continuous and free of audible crackling. If the service intentionally emits brief silent spans inside active speech, the generated/encoded stream should use transitions that do not create audible artifacts.

No audio recordings, credentials, session identifiers, or private transcripts are attached. I can provide sanitized timing and waveform summaries if useful.

No source files or tests are named. Start by reproducing the issue with captured RTP PCM and compare the fixed-cadence offline Opus decode, live GStreamer decode, and PulseAudio monitor capture on the WSL2 PulseAudio RDPSink path. Done means identifying whether the short silent intervals originate in the received/generated stream or the downstream speaker path and eliminating the audible crackle.