fix(relay): widen per-peer audio channel capacity 8->16 frames - #4178
Open
brunkstr wants to merge 1 commit into
Open
fix(relay): widen per-peer audio channel capacity 8->16 frames#4178brunkstr wants to merge 1 commit into
brunkstr wants to merge 1 commit into
Conversation
Jitter spikes of 150-152ms on an ordinary residential-ISP path to the relay sit right at the old 160ms (8-frame) ceiling, so brief jitter was enough to make try_send drop frames outright -- audible as grain, not lag. Widening to 320ms (16 frames) raises the drop threshold. This does not recover lost audio content, only reduces how often the relay drops frames under jitter. Receive-side Opus FEC would recover content but needs a fork of the upstream neteq crate (no fec-aware decode entry point as of neteq 0.9.0) -- tracked separately in block#4177. Co-authored-by: brunkstr <132263425+brunkstr@users.noreply.github.com> Signed-off-by: brunkstr <132263425+brunkstr@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
AUDIO_CHANNEL_CAPACITYincrates/buzz-relay/src/audio/room.rsgates the per-peermpscchannel the relay fans audio frames out through; at 8 frames (160ms) it sits right at the jitter ceiling for an ordinary residential-ISP path, sotry_sendwas dropping frames outright under normal jitter — heard as audio grain, not lag.neteqcrate — tracked separately in Huddle: receive-side Opus in-band FEC for lossy relay paths #4177).Context
Diagnosed live against the
web3servicesGKE deployment (buzz-cluster) — pod CPU/mem were near-idle (ruling out a sizing/resourcing cause), but pings to the relay's LB IP showed jitter spikes of 150-152ms sitting right at the old 160ms channel-capacity ceiling.Test plan
cargo test -p buzz-relay audio::room— 9/9 passcargo fmt -p buzz-relay -- --check— cleancargo clippy -p buzz-relay --all-targets -- -D warnings— cleanweb3servicesrelay deployment (pending maintainer go-ahead to redeploy — this PR does not itself deploy anything)Co-Authored-By: brunkstr 132263425+brunkstr@users.noreply.github.com