{"id":1469,"date":"2026-10-23T23:27:01","date_gmt":"2026-10-23T23:27:01","guid":{"rendered":"https:\/\/bestdedicatedwebhostingserver.com\/blog\/?p=1469"},"modified":"2026-10-23T23:27:01","modified_gmt":"2026-10-23T23:27:01","slug":"voice-chat-codec-bandwidth-game-servers","status":"publish","type":"post","link":"https:\/\/bestdedicatedwebhostingserver.com\/blog\/voice-chat-codec-bandwidth-game-servers\/","title":{"rendered":"Voice Chat Bandwidth on a Game Server: Opus vs PCM, Per-Slot Cost, and the 20\/50\/100 Player Math"},"content":{"rendered":"
A single player speaking on Opus at 32 kbit\/s generates about 4 KB of payload per second \u2014 but at 100 concurrent players that same codec quietly consumes 6\u201312 Mbit\/s of bidirectional bandwidth once packet headers, relay fan-out, and jitter buffers are counted. Voice is the part of a game server’s bandwidth budget that scales with the square of activity, not with slot count, and it is where most capacity plans go wrong.<\/p>\n\n
Every figure below is derived from codec bitrate, 20 ms packetisation, RTP\/UDP\/IP headers, and the relay model, so each one is reproducible.<\/p>\n\n
Opus vs PCM: What the Bitrate Actually Costs<\/h2>\n\n
Uncompressed PCM at 48 kHz, 16-bit mono is 768 kbit\/s, and stereo doubles it. That is fine point-to-point and absurd for a relay fanning one speaker to 99 listeners, where a single voice would consume 76 Mbit\/s of egress.<\/p>\n\n
Opus in voice mode is transparent for speech around 24\u201332 kbit\/s, good at 16 kbit\/s, and artefacted at 8 kbit\/s. Narrowband modes land at 8\u201312 kbit\/s and degrade badly under background game audio.<\/p>\n\n
Opus is variable bitrate by design. A speaker averaging 24 kbit\/s can burst to 40\u201360 kbit\/s on a plosive, so capacity planning should use the configured cap plus 50% headroom rather than the average. If the encoder is not capped, the burst is whatever the complexity estimator decides that frame needs.<\/p>\n\n
Packetisation Overhead Nobody Budgets<\/h2>\n\n
A 20 ms frame at 32 kbit\/s carries 80 bytes of Opus payload. Add a 12-byte RTP header, 8 bytes of UDP, and 20 bytes of IPv4: 40 bytes of overhead on 80 bytes of payload, a 50% tax before any tunnel. With encapsulation, expect 60 bytes or more.<\/p>\n\n
# egress bandwidth per listener for one speaker\ngross_bps = (payload_bytes + 40) * 8 \/ 0.020 # 20 ms frames\n# 32 kbit\/s Opus -> (80 + 40) * 8 \/ 0.02 = 48,000 bps\n# 24 kbit\/s Opus -> (60 + 40) * 8 \/ 0.02 = 40,000 bps<\/code><\/pre>\n\n
So a 32 kbit\/s stream costs 48 kbit\/s on the wire. Over a 100 Mbit\/s port that looks trivial; through a relay fanning out to every listener it multiplies fast. Frames also arrive every 20 ms regardless of whether anyone is mid-sentence, because comfort noise and DTX settings govern silence.<\/p>\n\n
Discontinuous transmission saves roughly 40\u201360% on typical conversational traffic, but only if the encoder supports it at the source; a relay cannot invent silence it never received.<\/p>\n\n
UDP vs TCP: Why Voice Cannot Use TCP<\/h2>\n\n
Voice belongs on UDP, and this is not a preference. TCP’s head-of-line blocking means one lost packet stalls every later packet until the retransmit arrives. On a 2% loss path that turns one 80-byte frame into 200\u2013400 ms of added latency on the whole stream.<\/p>\n\n
UDP drops the packet and moves on; a 20 ms Opus frame is concealed by the decoder from the previous frame’s spectrum. The right loss strategy is forward error correction (1\u20132 redundant frames), costing 20\u201330% extra bandwidth for direct resilience.<\/p>\n\n
TCP suits the relay’s control channel \u2014 join, mute, codec change \u2014 where reliability matters and volume is negligible. Separate sockets let the control plane stay synchronous while the media plane degrades.<\/p>\n\n
The Relay Fan-Out Problem<\/h2>\n\n
Two architectures give very different egress. A peer-to-peer mesh has every client send to every other, so each client’s upstream is (N-1) \u00d7 48 kbit\/s \u2014 at 17 speakers, 768 kbit\/s per client, which breaks consumer connections immediately.<\/p>\n\n
Server relay sends each client one stream and receives one from each active speaker. Server ingress is then speakers \u00d7 48 kbit\/s and egress is listeners \u00d7 (per-mixed-stream cost). The server’s CPU does the mixing, and that mixing cost is the real constraint: mixing 10 active streams at 20 ms frames is 50 mix operations per second per listener.<\/p>\n\n
Those figures exclude overhead on the egress side, which is another 40 bytes per 20 ms packet per listener \u2014 16 kbit\/s each. At 100 players that adds 1.6 Mbit\/s, pushing the realistic total to roughly 7.8 Mbit\/s. This is the number to put in the capacity plan, not the 6.2 figure.<\/p>\n\n
Jitter Buffer Headroom<\/h2>\n\n
The jitter buffer is deliberate delay that absorbs variance: no bandwidth cost, all of it paid in responsiveness. 60 ms covers typical internet variance; 200 ms survives a congested home uplink but feels like a satellite call. Most stacks default to 100\u2013200 ms, which is too much for competitive play.<\/p>\n\n
Adaptive buffers, which grow and shrink with observed variance, are the right choice. Size the ceiling from p99 jitter plus one frame interval: 45 ms jitter with 20 ms frames needs 80 ms, and anything more buys protection you pay for in perceived lag.<\/p>\n\n
The buffer does not reduce bandwidth, only delivery timing, so a server provisioned exactly at the computed bitrate still sees bursts when a listener reconnects and requests catch-up frames.<\/p>\n\n
Fitting Voice Into the Server’s Bandwidth Budget<\/h2>\n\n
Replication for 100 players at 60 Hz typically runs 25\u201340 Mbit\/s egress, so 7.8 Mbit\/s of voice is a 20\u201330% increase. That is fine on a 250 Mbit\/s commit and is the component that breaks a 100 Mbit\/s shared uplink also carrying updates, backups, and log shipping.<\/p>\n\n