Highly Robot PS5 Discord Users

dark commented

2026-06-20 01:54:44 +00:00

Owner

We have a particular hyena on our discord server who connects from their PS5. Their voice is always incredibly robotic, I suspect it has something to do with their console discord client. More investigation is needed.

dark added the

bug

label

2026-06-20 01:54:44 +00:00

robocub commented

2026-07-03 03:02:51 +00:00

Collaborator

Refined diagnosis (2026-07-03): the distortion is introduced in our songbird voice-receive/opus-decode of her stream — not her Discord client, and not our audio core.

Evidence, captured with [discord] capture_wav on:

Tap A (capture_<ssrc>.wav = what we receive from Discord) and Tap B (publish_<key>.wav = what we send to Matrix) are statistically identical (same RMS, same spectral profile) → our capture→publish pipeline is transparent, it adds no distortion.
The user confirms Spooki sounds fine in a normal Discord client, yet the captured PCM is already distorted — ~3.5× the >6 kHz energy of a normal speaker (HF fraction 0.07 vs 0.02), the harsh/robotic signature, present at the songbird decode point.
Spooki is a console (PS) user; SSRC 19412.

Conclusion: the lead is songbird’s opus decode and/or DAVE handling of a console client’s packet stream, not the bridge audio core (which is exonerated by capture==publish). Next investigation: compare songbird decode config / DAVE frame handling for console vs desktop senders.

**Refined diagnosis (2026-07-03): the distortion is introduced in our songbird voice-receive/opus-decode of her stream — not her Discord client, and not our audio core.** Evidence, captured with `[discord] capture_wav` on: - Tap A (`capture_<ssrc>.wav` = what we receive from Discord) and Tap B (`publish_<key>.wav` = what we send to Matrix) are **statistically identical** (same RMS, same spectral profile) → our capture→publish pipeline is transparent, it adds no distortion. - The user confirms Spooki sounds **fine in a normal Discord client**, yet the captured PCM is **already distorted** — ~3.5× the >6 kHz energy of a normal speaker (HF fraction 0.07 vs 0.02), the harsh/robotic signature, present at the songbird decode point. - Spooki is a console (PS) user; SSRC 19412. Conclusion: the lead is **songbird’s opus decode and/or DAVE handling of a console client’s packet stream**, not the bridge audio core (which is exonerated by capture==publish). Next investigation: compare songbird decode config / DAVE frame handling for console vs desktop senders.

robocub referenced this issue from a commit

2026-07-05 00:04:25 +00:00

fix(discord): songbird DAVE supplemental-trailer decode corruption (#36)

robocub referenced this issue from a commit

2026-07-05 01:24:09 +00:00

release: 0.3.0-alpha.5

robocub commented

2026-07-05 15:31:38 +00:00

Collaborator

Root-caused and fixed — it was never her client. Shipped v0.3.0-alpha.5.

songbird 0.6.0's DAVE receive path hands successfully-decrypted packets to the Opus decoder with the DAVE supplemental section still appended (≥11 trailing non-audio bytes: truncated AES-GCM tag, ULEB128 nonce, size byte, 0xFAFA magic). Opus codes "raw bits" backwards from the end of the frame (RFC 6716 §4.1), where CELT stores PVQ signs and fine energy — so the trailer silently corrupts every CELT/hybrid frame while SILK-only frames (coded from the front) pass clean. That's why it was speaker- and content-dependent, why no error was ever logged, and why the PS5 sender — whose encoder apparently lives in end-sensitive modes — was robotic essentially always while others flickered in and out.

The #32 per-SSRC WAV taps pinned the corruption to decode output (present in Tap A, zero opus/DAVE errors, no loss counters moving); the fix carries the receive-time corrected payload tail through songbird's playout buffer so the decoder gets the true plaintext slice. Shipped as a vendored patched songbird (vendor/songbird + davey 0.1.4) in v0.3.0-alpha.5 — listeners confirmed the PS5 speaker clean the moment the patched build went live, and she's stayed clean since.

Remaining, tracked in #57: submit the upstream songbird issue (write-up ready), offer the patch as a PR, and unwind vendor/songbird + the [patch.crates-io] override once a fixed songbird release exists to pin. Closing — the user-facing bug is dead.

**Root-caused and fixed — it was never her client. Shipped v0.3.0-alpha.5.** songbird 0.6.0's DAVE receive path hands successfully-decrypted packets to the Opus decoder with the **DAVE supplemental section still appended** (≥11 trailing non-audio bytes: truncated AES-GCM tag, ULEB128 nonce, size byte, `0xFAFA` magic). Opus codes "raw bits" backwards **from the end of the frame** (RFC 6716 §4.1), where CELT stores PVQ signs and fine energy — so the trailer silently corrupts every CELT/hybrid frame while SILK-only frames (coded from the front) pass clean. That's why it was speaker- and content-dependent, why no error was ever logged, and why the PS5 sender — whose encoder apparently lives in end-sensitive modes — was robotic essentially always while others flickered in and out. The #32 per-SSRC WAV taps pinned the corruption to decode output (present in Tap A, zero opus/DAVE errors, no loss counters moving); the fix carries the receive-time corrected payload tail through songbird's playout buffer so the decoder gets the true plaintext slice. Shipped as a **vendored patched songbird** (`vendor/songbird` + davey 0.1.4) in v0.3.0-alpha.5 — listeners confirmed the PS5 speaker clean the moment the patched build went live, and she's stayed clean since. Remaining, tracked in #57: submit the upstream songbird issue (write-up ready), offer the patch as a PR, and unwind `vendor/songbird` + the `[patch.crates-io]` override once a fixed songbird release exists to pin. Closing — the user-facing bug is dead.

robocub closed this issue

2026-07-05 15:31:38 +00:00

robocub referenced this issue

2026-07-05 15:31:39 +00:00

Audio "corrosion" #32

robocub referenced this issue

2026-07-05 15:41:11 +00:00

Unwind vendored songbird once the upstream DAVE-trailer fix lands #57

robocub referenced this issue

2026-07-26 03:53:20 +00:00

fix(discord): external displacement during puppet media-startup breaks recovery — rejoin succeeds but playback stays silent (deterministic; was masked by voice-state lag) #127

robocub referenced this issue