Audio "corrosion" #32

New issue

Closed

opened 2026-06-19 11:47:58 +00:00 by CreoSm · 1 comment

CreoSm commented

2026-06-19 11:47:58 +00:00

I've observed that sometimes the bot will send seemingly random audio output from discord to matrix at random intervals which is (extremely) unpleasant to hear.

dark added the

bug

label

2026-06-19 15:27:21 +00:00

robocub referenced this issue from a commit

2026-06-19 21:29:17 +00:00

feat(diag): Discord→Matrix audio-corrosion taps + counters (#32)

robocub referenced this issue from a commit

2026-06-19 21:57:41 +00:00

ci+docs: publish standalone x86_64 tarball + SHA256SUMS; document diagnostics & future directions

robocub referenced this issue from a commit

2026-06-20 00:40:09 +00:00

docs+ci: release-prep for v0.2.0

dark referenced this issue

2026-06-23 18:20:35 +00:00

Automatic Testing #38

robocub referenced this issue

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

Highly Robot PS5 Discord Users #36

robocub commented

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

Collaborator

Closing as presumed fixed by #36 (v0.3.0-alpha.5). The "random unpleasant audio at random intervals" matches the DAVE-trailer decode corruption exactly: songbird fed the Opus decoder frames with the DAVE supplemental section still appended, corrupting CELT/hybrid frames whenever a sender's encoder was in an end-sensitive mode — intermittent, content-dependent, and invisible in logs, which is precisely the "corrosion" signature.

Credit where due: the diagnostic instrumentation built for this issue (per-SSRC Tap A/B WAVs + counters) is what proved the corruption was already present at decode output and pinned it to songbird's receive path.

No corrosion has been reported since alpha.5 went live. Reopen if it's ever heard again on ≥ v0.3.0-alpha.5.

Closing as **presumed fixed by #36** (v0.3.0-alpha.5). The "random unpleasant audio at random intervals" matches the DAVE-trailer decode corruption exactly: songbird fed the Opus decoder frames with the DAVE supplemental section still appended, corrupting CELT/hybrid frames whenever a sender's encoder was in an end-sensitive mode — intermittent, content-dependent, and invisible in logs, which is precisely the "corrosion" signature. Credit where due: the diagnostic instrumentation built for this issue (per-SSRC Tap A/B WAVs + counters) is what proved the corruption was already present at decode output and pinned it to songbird's receive path. No corrosion has been reported since alpha.5 went live. Reopen if it's ever heard again on ≥ v0.3.0-alpha.5.

robocub closed this issue

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