FiveM Voice Chat: Diagnosing and Fixing Common Problems

how FiveM voice actually works

FiveM ships with a Mumble voice server built directly into FXServer. Most servers run pma-voice, which isn't itself a voice server. It's a wrapper resource that configures FiveM's built-in Mumble system and adds the features players expect: proximity audio, radio, phone calls, submixes, and routing bucket support.

That distinction matters when you're troubleshooting. pma-voice can be configured perfectly while the underlying voice transport is still falling over, and the reverse is true too. So when someone says "pma-voice is broken," the actual fault is often one layer below it.

One more thing worth knowing up front: the built-in Mumble server runs inside the FXServer process, and it's effectively single-threaded. That turns out to be the defining constraint on busy servers, which we'll get to.

Step 1: Figure out the scope

Before changing anything, work out how far the problem spreads. This one question knocks out most of the possibilities.

Skipping this step is the single biggest time-waster. Rebuilding your voice infrastructure won't do much if one player has their Windows output device pointed at a monitor they never use.

Symptom: robotic, choppy, or stuttering audio when the server is busy

What it looks like: Voice is perfectly fine on a quiet server or during testing, then degrades noticeably at peak. Audio goes robotic or breaks into fragments. It gets worse when players cluster up (a club, a city hall meeting, a big scene) and clears up when they scatter.

What's happening: The Mumble server embedded in FXServer is saturating. Because it runs in-process and is effectively single-threaded, it'll bottleneck on one core's worth of work long before your machine's overall CPU or RAM shows any pressure at all. Operators running standalone Mumble alongside FiveM consistently report that the embedded server pegs a core and chews through noticeably more bandwidth than a dedicated Mumble daemon doing the same job.

Here's the key insight: proximity voice cost scales with overlapping audio ranges, not raw player count. Every speaking player's audio has to be routed to everyone within earshot, so 60 players packed into one block is far more expensive than 200 spread across the map. That's why this problem usually gets described as event-driven rather than count-driven.

Worth flagging: you can't fix this by adding CPU cores, RAM, or bandwidth to the machine. The limit is one thread inside one process.

Fix: Move voice off FXServer onto a dedicated voice server. Details below.

Symptom: some players can't hear or be heard, and a client restart fixes it

What it looks like: A subset of players have no working voice at all. They can't hear anyone, and nobody can hear them. Radio may or may not work. They fully close and reopen FiveM, and everything's fine again. Nothing useful in the server console.

What's happening: Those players never got moved into their voice channel, so they're sitting in the Mumble root channel. The client didn't receive the mumbleConnected event, which means pma-voice's initial state handling never ran. They're technically connected to the voice server, just never placed anywhere useful.

Large servers have reported this as a scaling failure: the more players connecting in a short window, the more likely some connections slip through. It's a genuinely separate problem from audio degradation, even though players will describe both as "voice not working."

The tell: a client restart fixes it. Capacity-related audio degradation doesn't behave that way.

Fix: This one is a known limitation at scale rather than something you've misconfigured. Turn on voice_debugMode (1 for basic logs, 4 for verbose) to confirm the connection sequence is where it's failing. Moving to a dedicated voice server reduces it but doesn't always eliminate it, so keep pma-voice and your voice server current, since this has seen active work.

Symptom: voice broke server-wide right after a change

What it looks like: Voice was working, someone added or updated a resource, and now it's dead for everyone.

What's happening: Nearly always a conflict. Either a second voice system is running, or a script is stepping on the Mumble natives that pma-voice needs to own.

Fix, in this order:

1. Confirm only one voice resource is running. Older resources like mumble-voip, esx_voice, vdk_voice, or tokovoip will fight pma-voice. Remove them properly rather than just stopping them.
2. Check vMenu. vMenu's built-in voice chat is a very common culprit and needs to be disabled if you're on pma-voice.
3. Audit for native overrides. pma-voice has to exclusively control the following. Any other resource calling them will cause problems:
   • NetworkSetTalkerProximity
   • MumbleSetTalkerProximity
   • MumbleSetAudioInputDistance
   • MumbleSetAudioOutputDistance
   • NetworkSetVoiceActive
4. Check load order. Convars need to be set in server.cfg before the ensure pma-voice line, otherwise they won't apply at startup.

Symptom: voice broke right after setting up an external voice server

What it looks like: Everything worked on the built-in server. You added voice_externalAddress and voice_externalPort, and now players connect (the UI indicator lights up when they talk) but nobody can hear anybody.

The usual suspects:

• Address format. voice_externalAddress wants a hostname or IP and nothing else. No http:// or https:// prefix, no trailing path.
• Port reachability. Check the voice port is reachable from the public internet, not just from the server itself. Test it from an outside network. Standalone Mumble defaults to 64738.
• Firewall rules. Make sure both TCP and UDP are open on the voice port.
• DNS. If you're using a hostname, confirm it resolves from a client machine, not just from the server.

The relevant convars:

setr voice_externalAddress "voice.yourdomain.com"
setr voice_externalPort 64738
setr voice_hideEndpoints 1
setr voice_externalDisallowJoin 0

voice_hideEndpoints keeps the voice address out of logs, which matters a bit more once you're running a separate endpoint. voice_externalDisallowJoin is only for when you're using a second FXServer instance as your voice server.

The fix for capacity problems: a dedicated voice server

If you've confirmed the problem is load-related, the answer is getting voice processing out of FXServer.

Is it worth doing? Common guidance puts the threshold around 60+ concurrent players, or earlier if your server sees heavy clustering during events. Below that, the built-in server is usually fine and the extra complexity isn't really earning its keep. It's also worth a look if you deal with DDoS attacks, since separating voice keeps comms alive while the game server's network path is under pressure.

Your options:

Run the voice server on a separate host, or at minimum a separate container from your game server. Putting it on the same box gets you some of the benefit (you're no longer sharing a process) but you're still sharing a CPU and a network path.

Diagnostic checklist

Run through this before escalating or rebuilding anything:

• Scope identified: one player, some players, or everyone?
• Does it correlate with player count or specific in-game events?
• All voice, or just radio and phone?
• Only one voice resource installed and running
• vMenu voice disabled
• No third-party script calling the Mumble proximity natives
• Convars set before ensure pma-voice in server.cfg
• resmon checked during a failure window: is the server hitching generally?
• voice_debugMode 4 enabled to capture the connection sequence
• If external: bare hostname or IP, port reachable from outside, firewall allows TCP and UDP
• Server and pma-voice both on current recommended versions

Getting better reports out of players

Player reports about voice are unusually vague, and it's not their fault. They're describing the experience, not the behavior, and "voice is broken" happens to cover at least four unrelated faults.

Worth asking:

• Could they hear others, be heard, or neither?
• Did radio and phone work when proximity didn't?
• Roughly how many players were online, and were they in a crowd?
• Did restarting FiveM fix it, and if so, for how long?
• What time of day, so you can line it up against server metrics?

Two or three specific reports beat twenty vague ones, and honestly the "did a restart fix it" question alone separates the two most common failure modes.

Quick reference: useful pma-voice convars

All pma-voice settings are convar-driven and changeable at runtime, so most configuration tweaks won't need a full server restart.

Convar names and defaults do shift between releases, so it's worth checking anything here against the current pma-voice README.