FiveM voice stutter: is it really bandwidth? pma-voice/Mumble explained, and when a separate voice server is worth it (2026)

"Voice is choppy" is the second most common complaint after stuck loading. It shows up as gaps, a robotic voice, a 1–2 second delay, or hearing people far away but not the one next to you. Admins usually conclude "not enough bandwidth, we need a separate voice server". The short answer depends on server size. At 64–128 players bandwidth is the cause in a minority of cases; most of the time it is server hitching, packet loss on the route (including DDoS-protection proxies), and pma-voice settings that send audio to far more people than necessary. At 1,000–2,048 players (the big Thai cities) bandwidth and CPU become very real, and the built-in Mumble is out from day one. This post goes from how audio travels, through real numbers at both scales and diagnosis, to how to run a separate voice server for two thousand people.

How voice travels in FiveM

FXServer ships with a built-in Mumble server on the same port as the game (default 30120, TCP and UDP). Nothing extra to install. pma-voice does not carry audio; its job is to tell Mumble who should hear whom (voice targets) based on distance, radio channels and phone calls.

The path of one spoken sentence:

1. The client encodes audio with Opus at roughly 40–72 kbps and sends it to the server over UDP
2. The server copies it to everyone in the speaker's target: players in range, everyone on the radio channel being keyed, the call partner
3. Each receiving client decodes it and places it in 3D

Two consequences everything below rests on:

• Server upload = simultaneous speakers × listeners per speaker × bitrate. One speaker heard by 60 people costs 60× the original stream
• Mumble uses UDP first and falls back to sending audio over TCP if UDP does not get through. TCP waits for a lost packet before delivering the next ones (head-of-line blocking), so audio stops and then arrives in a burst. This is the most common "voice stutters while the game does not lag"

Real bandwidth math

Apply the formula with 48 kbps (the practical mid value in FiveM).

Add the game's own sync (OneSync) at roughly 150–400 kbps per player depending on entity density around each player (OneSync Infinity only sends nearby entities, so the per-player figure does not grow with population, but the total does): 64 players ≈ 10–25 Mbps, 128 ≈ 20–50 Mbps, 2,000 ≈ 300–800 Mbps.

Bottom line:

• 32–64 players: game plus voice peaks at 15–40 Mbps. A 100 Mbps port that is not shared handles it
• 128 players with gatherings: peaks of 60–100 Mbps. A 100 Mbps port really does saturate; you need 1 Gbps
• 1,000–2,048 players: game sync alone eats half to all of a 1 Gbps port before voice is counted. 1 Gbps is not enough at peak; you need 2.5–10 Gbps dedicated, and voice must live on another machine (next section)
• Player download is almost never the problem: hearing 10 people at once is 0.5 Mbps, fine on mobile data

"Not enough bandwidth" in practice comes in exactly three shapes: a VPS on a 100 Mbps port shared with other customers on the host, "unmetered" plans with a fair-use clause that throttle heavy use, and "1 Gbps burst" that only holds for seconds. If you are in one of those, read the hosting section. If not, the cause is elsewhere.

At 1,000–2,048 players the rules change

OneSync Infinity allows up to 2,048 slots (Element Club Platinum), and several large Thai servers really run at 1,000–2,000 concurrent players. At that scale four conclusions from small servers no longer hold:

1. The built-in Mumble is out from day one. It lives in the same process as the main thread that syncs entities for two thousand people. One 30 ms hitch on that thread stutters voice for the whole server at once, and at this scale small hitches happen every minute no matter how well you optimise. Splitting Mumble out is not an option, it is a requirement
2. Bandwidth is real. Game sync at 300–800 Mbps plus 40–60 Mbps of voice in normal hours. A 1 Gbps port that looks generous for 128 players saturates at a two-thousand-player peak. What servers this size actually run is 2.5–10 Gbps dedicated on the game machine and a separate dedicated 1 Gbps for the voice machine
3. Speaking range and sendingRangeOnly are survival, not savings. The table shows it: a 300-person event with wide ranges = 430 Mbps of voice alone; 6 m range plus voice_useSendingRangeOnly = 36 Mbps for the same event, a 12× difference
4. Radio is a time bomb. A 150-person police channel on a two-thousand server is 150 listeners per key-up; five people keying at once is 36 Mbps from one channel. Split channels by district or unit, cap them at 30–40 members, and keep a broadcast channel that only leads can key

The layout servers at this level use: a game machine with the highest single-thread clock available (the FXServer main thread is one thread), a separate Mumble machine (also high clock, since murmur routes packets on one main thread; users above 2,048, bandwidth lowered to 48000 to bound the total), and DDoS scrubbing at the network edge that passes UDP without a tunnel, because a server this size will be attacked. The external Mumble setup is at the end of this post; the only values that differ from a small server are users and bandwidth.

Diagnose before fixing, in this order

1. One player or everyone? One player choppy while others at the same spot are fine = that player's machine or connection; skip to the player section. Everyone at once = server or route
2. Only when people gather (events, market, weddings) = server upload or CPU. Watch the server console at that moment: server thread hitch warning means the main thread stalls, and the Mumble server living in the same process stalls with it. Check NIC load with nload or vnstat -l on the host
3. Voice stutters but the game does not lag (cars do not warp, doors open normally) = the voice UDP path: a DDoS-protection proxy wrapping UDP, a firewall blocking UDP, or a player connection dropping UDP until Mumble falls back to TCP
4. 1–2 seconds of delay without gaps = TCP fallback almost certainly. Audio arrives complete but late
5. The decisive test: point voice at a separate Mumble server temporarily (setup at the end). Symptoms gone instantly = the game process or the proxy is the bottleneck. Still choppy = network route or player side; no need to pay for a permanent split

Player side: five checks before blaming the server

• Type netgraph 1 in F8 and watch loss and ping. Periodic loss = voice drops on that rhythm. Try a phone hotspot; if it clears up, it is the ISP or the router
• Turn off every VPN. Most VPNs drop or delay UDP until Mumble falls back to TCP
• Bluetooth microphones use the phone profile (HFP), low quality and laggy. Switch to a wired or USB mic
• Windows › Sound: set both mic and headset to 48000 Hz. Mismatched rates crackle and stutter
• Discord or OBS capturing the same mic with noise suppression eats CPU on a client already rendering the game. Close them to test (resmon 1 in F8 shows what eats frames; see FiveM UI lag, NUI eating FPS)

Fix pma-voice first: free and immediate

The cause you control 100% is "sending audio to more people than necessary". Set it in server.cfg and pma-voice/config.lua.

# server.cfg
setr voice_useNativeAudio true
setr voice_useSendingRangeOnly true

• voice_useSendingRangeOnly true makes the server send audio only to players actually within hearing range. The default sends to a wider radius and lets the client attenuate. This one line halves upload during events
• voice_useNativeAudio true uses the game's audio engine for positioning; volume falls off with distance and walls realistically. Not a bandwidth setting, but it removes the "I hear people far away" reports players describe as broken voice
• Speaking ranges in config.lua: Cfg.voiceModes = { {2.5, "Whisper"}, {6.0, "Normal"}, {14.0, "Shouting"} }. Many servers set Normal 15 and Shout 30, so the whole market hears everyone and listeners per speaker jump from 6 to 40. The defaults are enough for RP and cut the most load
• Radio: every key-up goes to everyone on the channel. A 40-person police channel is 40 listeners per key-up. Split channels per unit, cap members per channel, keep a shared channel for announcements only
• Enforce push-to-talk. A player on voice activation is a "speaker" all the time, including breathing. At a 60-person event where half use VA, simultaneous speakers become 30, not 8; the table above quadruples instantly
• Phone calls over pma-voice are cheap: the call partner is one listener (X3D Phone calls through the pma-voice adapter directly)

Fix the server and the host

CPU and hitches. The built-in Mumble lives in the game process. When the main thread stalls on a heavy resource (tight loops, synchronous SQL, entity spam), voice stalls too. In the console run profiler record 500, wait, then profiler save voice and open it in Chrome tracing to see which resource eats time per frame. txAdmin › Resources shows thread time per resource as well. Fix the heavy one before buying anything.

DDoS-protection proxies that wrap UDP. Many protection services work as a reverse proxy or tunnel: player packets go to a scrubbing node first, then on to you. Every hop adds jitter and voice shows it first. Pick a host that filters DDoS at the network edge in front of the machine, not through a tunnel; or, if unavoidable, let voice go direct with an external Mumble (next section).

Port and location. 1 Gbps dedicated, not shared, from 96 players up. Located in the same region as your players with good peering to their ISPs. Test with mtr from home connections on the major ISPs; a hop with constant loss means moving hosts beats any config change.

Firewall. Open 30120 for both TCP and UDP (game and voice share it). Some hosts open TCP only, and the whole server silently falls back to TCP voice.

OneSync. onesync_distanceCullVehicles true stops syncing far vehicles and frees upload for voice on machines with a limited port.

Is a separate voice server (external Mumble) necessary?

Not necessary for servers up to 64–96 players with the settings above; the built-in Mumble handles it. Mandatory from about 500 players. Worth it when any of these apply:

1. 128+ players with regular gatherings
2. The game server is CPU-bound and hitching, resources cannot be fixed in time, and you want voice out of that process now
3. You use a tunnel-style DDoS proxy and want voice to reach players directly
4. The game server is abroad but you want voice on a machine close to the players for low ping
5. 500 players or more: do not wait for symptoms, split on launch day

What you gain: a separate process, CPU and NIC; your own bitrate and user caps; voice unaffected by game hitches. What you pay: another machine (or container) to maintain, a voice IP that players connect to directly and that can therefore be attacked, and a Mumble version that works with FiveM (1.4 or newer).

Setup in 10 minutes (Docker)

On the voice machine (Linux, port 64738 TCP+UDP open):

docker run -d --name mumble --restart unless-stopped \
  -p 64738:64738/tcp -p 64738:64738/udp \
  -e MUMBLE_CONFIG_USERS=2200 \
  -e MUMBLE_CONFIG_BANDWIDTH=48000 \
  -e MUMBLE_CONFIG_OPUS_THRESHOLD=0 \
  -e MUMBLE_CONFIG_MESSAGE_LIMIT=999999 \
  -e MUMBLE_CONFIG_MESSAGE_BURST=999999 \
  -e MUMBLE_CONFIG_WELCOME_TEXT="" \
  -v mumble-data:/data \
  mumblevoip/mumble-server:latest

The values that matter (with a package install, put the lowercase names in murmur.ini):

Then in the game server's server.cfg:

setr voice_externalAddress "203.0.113.10"   # public IP of the voice machine
setr voice_externalPort 64738

Restart pma-voice, join, open F8: the Mumble line should show a connection to the new IP. Test with two players at 3 m and 20 m; if distance behaves, positional audio works.

Note: SaltyChat and TokoVoip run on TeamSpeak, not Mumble. This post applies to pma-voice and mumble-voip only.

Admin checklist

# server.cfg
setr voice_useNativeAudio true
setr voice_useSendingRangeOnly true
onesync_distanceCullVehicles true
# pma-voice/config.lua
Cfg.voiceModes = { {2.5, "Whisper"}, {6.0, "Normal"}, {14.0, "Shouting"} }

• Firewall: 30120 TCP+UDP (and 64738 TCP+UDP if voice is split)
• Radio channels of 20–30 at most, split per unit
• Push-to-talk in the server rules
• No server thread hitch warning in the console at peak hours
• Host: dedicated port, DDoS filtering at the network edge, not a tunnel
• 128+ players, or any of the four conditions above, before splitting to an external Mumble; from 500 players split on day one
• 1,000–2,048 players: game machine 2.5–10 Gbps dedicated, separate 1 Gbps voice machine, users=2200, bandwidth=48000, 6 m speaking range, radio channels capped at 30–40

FAQ

Can I change the bitrate of the built-in Mumble? No server-side setting; FiveM uses its own mid value. To cap it you need an external Mumble and bandwidth.

1–2 seconds of delay but no gaps? TCP fallback almost every time. Check the server's UDP firewall first, then the player's VPN and router.

Just use Discord instead? As a temporary fallback when the server is down. You lose positional audio and radio; RP without distance gets stale fast.

pma-voice or SaltyChat? pma-voice is free, light, and needs nothing installed on the player's side. SaltyChat sounds slightly better but every player must install TeamSpeak and the plugin. Servers that want new players in fast pick pma-voice.

Still choppy after splitting voice? Then the bottleneck was never the game process. Back to the diagnosis section: network route (mtr) or player side. On a two-thousand-player server also check that the voice machine itself is not CPU-bound (murmur is single-threaded) or port-bound.

Can one Mumble server take 2,000 players? Yes, with a high-clock CPU and a 1 Gbps or better NIC; murmur handles thousands of users per instance. What kills it is not the head count but listeners per speaker from oversized ranges (the 430 Mbps row) and the default messagelimit throttling pma-voice's voice-target updates. pma-voice connects to a single voice_externalAddress, so voice cannot be sharded across machines; one machine has to be strong enough.

Want the team to go through your config, hitching resources and host together: FiveM server setup service. For joining and map problems see FiveM stuck on loading and FiveM map not loading.