[{"data":1,"prerenderedAt":52},["ShallowReactive",2],{"site":3,"blog-post-en-fivem-voice-stutter-pma-voice":15,"blog-slug-site":45,"blog-scripts-en-fivem-voice-stutter-pma-voice":51},{"site":4,"contact":10,"seo":13,"payment":14},{"name":5,"host":6,"default_locale":7,"locales":8},"X3D Developer","fivem.x3d-developer.com","th",[7,9],"en",{"discord_invite":11,"email":12,"line":12},"https:\u002F\u002Fdiscord.gg\u002FNA5kPVynFv","",{"google_site_verification":12,"bing_site_verification":12},{"bank_name":12,"account_name":12,"account_no":12,"promptpay_id":12},{"post":16,"html":21,"others":22,"productSlugs":44},{"slug":17,"title":18,"description":19,"date":20},"fivem-voice-stutter-pma-voice","FiveM voice stutter: is it really bandwidth? pma-voice\u002FMumble explained, and when a separate voice server is worth it (2026)","Choppy, robotic or delayed voice in FiveM is rarely bandwidth on a 64–128 slot server, but on 1,000–2,048 slots bandwidth and CPU are real. How pma-voice and the Mumble server built into FXServer move audio, real bandwidth math in Mbps, how to tell player vs server vs route problems, the pma-voice settings that cut load immediately, and when an external Mumble server pays off, with setup.","2026-09-27","\u003Cp>&quot;Voice is choppy&quot; 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 &quot;not enough bandwidth, we need a separate voice server&quot;. The short answer depends on server size. \u003Cstrong>At 64–128 players bandwidth is the cause in a minority of cases\u003C\u002Fstrong>; 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. \u003Cstrong>At 1,000–2,048 players (the big Thai cities) bandwidth and CPU become very real\u003C\u002Fstrong>, 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.\u003C\u002Fp>\n\u003Ch2 id=\"how-voice-travels-in-fivem\">How voice travels in FiveM\u003C\u002Fh2>\n\u003Cp>FXServer ships with a \u003Cstrong>built-in Mumble server\u003C\u002Fstrong> on the same port as the game (default \u003Ccode>30120\u003C\u002Fcode>, TCP and UDP). Nothing extra to install. pma-voice does not carry audio; its job is to \u003Cstrong>tell Mumble who should hear whom\u003C\u002Fstrong> (voice targets) based on distance, radio channels and phone calls.\u003C\u002Fp>\n\u003Cp>The path of one spoken sentence:\u003C\u002Fp>\n\u003Col>\n\u003Cli>The client encodes audio with Opus at roughly \u003Cstrong>40–72 kbps\u003C\u002Fstrong> and sends it to the server over UDP\u003C\u002Fli>\n\u003Cli>The server \u003Cstrong>copies\u003C\u002Fstrong> it to everyone in the speaker's target: players in range, everyone on the radio channel being keyed, the call partner\u003C\u002Fli>\n\u003Cli>Each receiving client decodes it and places it in 3D\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>Two consequences everything below rests on:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>Server upload = simultaneous speakers × listeners per speaker × bitrate.\u003C\u002Fstrong> One speaker heard by 60 people costs 60× the original stream\u003C\u002Fli>\n\u003Cli>Mumble uses \u003Cstrong>UDP first and falls back to sending audio over TCP\u003C\u002Fstrong> 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 &quot;voice stutters while the game does not lag&quot;\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2 id=\"real-bandwidth-math\">Real bandwidth math\u003C\u002Fh2>\n\u003Cp>Apply the formula with 48 kbps (the practical mid value in FiveM).\u003C\u002Fp>\n\u003Cdiv class=\"table-scroll\">\u003Ctable>\n\u003Cthead>\n\u003Ctr>\n\u003Cth>Scenario\u003C\u002Fth>\n\u003Cth>Simultaneous speakers\u003C\u002Fth>\n\u003Cth>Listeners per speaker\u003C\u002Fth>\n\u003Cth>Server upload from voice\u003C\u002Fth>\n\u003C\u002Ftr>\n\u003C\u002Fthead>\n\u003Ctbody>\n\u003Ctr>\n\u003Ctd>Normal RP, 64 players spread over the map\u003C\u002Ftd>\n\u003Ctd>10\u003C\u002Ftd>\n\u003Ctd>6\u003C\u002Ftd>\n\u003Ctd>10 × 6 × 48 kbps ≈ \u003Cstrong>2.9 Mbps\u003C\u002Fstrong>\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Event, 60 players in one spot\u003C\u002Ftd>\n\u003Ctd>8\u003C\u002Ftd>\n\u003Ctd>60\u003C\u002Ftd>\n\u003Ctd>8 × 60 × 48 kbps ≈ \u003Cstrong>23 Mbps\u003C\u002Fstrong>\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Police radio, 30 people on one channel\u003C\u002Ftd>\n\u003Ctd>1 keyed\u003C\u002Ftd>\n\u003Ctd>30\u003C\u002Ftd>\n\u003Ctd>1 × 30 × 48 kbps ≈ \u003Cstrong>1.4 Mbps per key-up\u003C\u002Fstrong>\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Market, 128-player server, half in one place\u003C\u002Ftd>\n\u003Ctd>15\u003C\u002Ftd>\n\u003Ctd>64\u003C\u002Ftd>\n\u003Ctd>15 × 64 × 48 kbps ≈ \u003Cstrong>46 Mbps\u003C\u002Fstrong>\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>2,000-player server, normal hours, spread out\u003C\u002Ftd>\n\u003Ctd>200\u003C\u002Ftd>\n\u003Ctd>6\u003C\u002Ftd>\n\u003Ctd>200 × 6 × 48 kbps ≈ \u003Cstrong>58 Mbps\u003C\u002Fstrong>\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>2,000-player server, 300-person event, wide ranges\u003C\u002Ftd>\n\u003Ctd>30\u003C\u002Ftd>\n\u003Ctd>300\u003C\u002Ftd>\n\u003Ctd>30 × 300 × 48 kbps ≈ \u003Cstrong>430 Mbps\u003C\u002Fstrong>\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Same event, 6 m range + sendingRangeOnly\u003C\u002Ftd>\n\u003Ctd>30\u003C\u002Ftd>\n\u003Ctd>25\u003C\u002Ftd>\n\u003Ctd>30 × 25 × 48 kbps ≈ \u003Cstrong>36 Mbps\u003C\u002Fstrong>\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003C\u002Ftbody>\n\u003C\u002Ftable>\n\u003C\u002Fdiv>\n\u003Cp>Add the game's own sync (OneSync) at roughly \u003Cstrong>150–400 kbps per player\u003C\u002Fstrong> 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, \u003Cstrong>2,000 ≈ 300–800 Mbps\u003C\u002Fstrong>.\u003C\u002Fp>\n\u003Cp>Bottom line:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>32–64 players\u003C\u002Fstrong>: game plus voice peaks at 15–40 Mbps. A 100 Mbps port that is not shared handles it\u003C\u002Fli>\n\u003Cli>\u003Cstrong>128 players with gatherings\u003C\u002Fstrong>: peaks of 60–100 Mbps. A 100 Mbps port really does saturate; you need 1 Gbps\u003C\u002Fli>\n\u003Cli>\u003Cstrong>1,000–2,048 players\u003C\u002Fstrong>: 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)\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Player download\u003C\u002Fstrong> is almost never the problem: hearing 10 people at once is 0.5 Mbps, fine on mobile data\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>&quot;Not enough bandwidth&quot; in practice comes in exactly three shapes: a VPS on a 100 Mbps port \u003Cstrong>shared\u003C\u002Fstrong> with other customers on the host, &quot;unmetered&quot; plans with a fair-use clause that throttle heavy use, and &quot;1 Gbps burst&quot; that only holds for seconds. If you are in one of those, read the hosting section. If not, the cause is elsewhere.\u003C\u002Fp>\n\u003Ch2 id=\"at-1-000-2-048-players-the-rules-change\">At 1,000–2,048 players the rules change\u003C\u002Fh2>\n\u003Cp>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:\u003C\u002Fp>\n\u003Col>\n\u003Cli>\u003Cstrong>The built-in Mumble is out from day one.\u003C\u002Fstrong> 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\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Bandwidth is real.\u003C\u002Fstrong> 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\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Speaking range and sendingRangeOnly are survival, not savings.\u003C\u002Fstrong> The table shows it: a 300-person event with wide ranges = 430 Mbps of voice alone; 6 m range plus \u003Ccode>voice_useSendingRangeOnly\u003C\u002Fcode> = 36 Mbps for the same event, a 12× difference\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Radio is a time bomb.\u003C\u002Fstrong> 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\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>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; \u003Ccode>users\u003C\u002Fcode> above 2,048, \u003Ccode>bandwidth\u003C\u002Fcode> 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 \u003Ccode>users\u003C\u002Fcode> and \u003Ccode>bandwidth\u003C\u002Fcode>.\u003C\u002Fp>\n\u003Ch2 id=\"diagnose-before-fixing-in-this-order\">Diagnose before fixing, in this order\u003C\u002Fh2>\n\u003Col>\n\u003Cli>\u003Cstrong>One player or everyone?\u003C\u002Fstrong> 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\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Only when people gather\u003C\u002Fstrong> (events, market, weddings) = server upload or CPU. Watch the server console at that moment: \u003Ccode>server thread hitch warning\u003C\u002Fcode> means the main thread stalls, and the Mumble server living in the same process stalls with it. Check NIC load with \u003Ccode>nload\u003C\u002Fcode> or \u003Ccode>vnstat -l\u003C\u002Fcode> on the host\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Voice stutters but the game does not lag\u003C\u002Fstrong> (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\u003C\u002Fli>\n\u003Cli>\u003Cstrong>1–2 seconds of delay without gaps\u003C\u002Fstrong> = TCP fallback almost certainly. Audio arrives complete but late\u003C\u002Fli>\n\u003Cli>\u003Cstrong>The decisive test\u003C\u002Fstrong>: 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\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Ch2 id=\"player-side-five-checks-before-blaming-the-server\">Player side: five checks before blaming the server\u003C\u002Fh2>\n\u003Cul>\n\u003Cli>Type \u003Ccode>netgraph 1\u003C\u002Fcode> 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\u003C\u002Fli>\n\u003Cli>Turn off every VPN. Most VPNs drop or delay UDP until Mumble falls back to TCP\u003C\u002Fli>\n\u003Cli>Bluetooth microphones use the phone profile (HFP), low quality and laggy. Switch to a wired or USB mic\u003C\u002Fli>\n\u003Cli>Windows › Sound: set both mic and headset to \u003Cstrong>48000 Hz\u003C\u002Fstrong>. Mismatched rates crackle and stutter\u003C\u002Fli>\n\u003Cli>Discord or OBS capturing the same mic with noise suppression eats CPU on a client already rendering the game. Close them to test (\u003Ccode>resmon 1\u003C\u002Fcode> in F8 shows what eats frames; see \u003Ca href=\"\u002Fen\u002Fblog\u002Ffivem-ui-lag\u002F\">FiveM UI lag, NUI eating FPS\u003C\u002Fa>)\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2 id=\"fix-pma-voice-first-free-and-immediate\">Fix pma-voice first: free and immediate\u003C\u002Fh2>\n\u003Cp>The cause you control 100% is &quot;sending audio to more people than necessary&quot;. Set it in \u003Ccode>server.cfg\u003C\u002Fcode> and \u003Ccode>pma-voice\u002Fconfig.lua\u003C\u002Fcode>.\u003C\u002Fp>\n\u003Cpre>\u003Ccode># server.cfg\nsetr voice_useNativeAudio true\nsetr voice_useSendingRangeOnly true\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cul>\n\u003Cli>\u003Ccode>voice_useSendingRangeOnly true\u003C\u002Fcode> makes the server \u003Cstrong>send audio only to players actually within hearing range\u003C\u002Fstrong>. The default sends to a wider radius and lets the client attenuate. This one line halves upload during events\u003C\u002Fli>\n\u003Cli>\u003Ccode>voice_useNativeAudio true\u003C\u002Fcode> uses the game's audio engine for positioning; volume falls off with distance and walls realistically. Not a bandwidth setting, but it removes the &quot;I hear people far away&quot; reports players describe as broken voice\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Speaking ranges\u003C\u002Fstrong> in \u003Ccode>config.lua\u003C\u002Fcode>: \u003Ccode>Cfg.voiceModes = { {2.5, &quot;Whisper&quot;}, {6.0, &quot;Normal&quot;}, {14.0, &quot;Shouting&quot;} }\u003C\u002Fcode>. 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\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Radio\u003C\u002Fstrong>: 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\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Enforce push-to-talk.\u003C\u002Fstrong> A player on voice activation is a &quot;speaker&quot; 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\u003C\u002Fli>\n\u003Cli>Phone calls over pma-voice are cheap: the call partner is one listener (\u003Ca href=\"\u002Fen\u002Fproducts\u002Fx3d-phone\u002F\">X3D Phone\u003C\u002Fa> calls through the pma-voice adapter directly)\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2 id=\"fix-the-server-and-the-host\">Fix the server and the host\u003C\u002Fh2>\n\u003Cp>\u003Cstrong>CPU and hitches.\u003C\u002Fstrong> 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 \u003Ccode>profiler record 500\u003C\u002Fcode>, wait, then \u003Ccode>profiler save voice\u003C\u002Fcode> 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.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>DDoS-protection proxies that wrap UDP.\u003C\u002Fstrong> 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 \u003Cstrong>at the network edge in front of the machine\u003C\u002Fstrong>, not through a tunnel; or, if unavoidable, let voice go direct with an external Mumble (next section).\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Port and location.\u003C\u002Fstrong> 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 \u003Ccode>mtr\u003C\u002Fcode> from home connections on the major ISPs; a hop with constant loss means moving hosts beats any config change.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Firewall.\u003C\u002Fstrong> Open \u003Ccode>30120\u003C\u002Fcode> 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.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>OneSync.\u003C\u002Fstrong> \u003Ccode>onesync_distanceCullVehicles true\u003C\u002Fcode> stops syncing far vehicles and frees upload for voice on machines with a limited port.\u003C\u002Fp>\n\u003Ch2 id=\"is-a-separate-voice-server-external-mumble-necessary\">Is a separate voice server (external Mumble) necessary?\u003C\u002Fh2>\n\u003Cp>\u003Cstrong>Not necessary\u003C\u002Fstrong> for servers up to 64–96 players with the settings above; the built-in Mumble handles it. \u003Cstrong>Mandatory\u003C\u002Fstrong> from about 500 players. \u003Cstrong>Worth it\u003C\u002Fstrong> when any of these apply:\u003C\u002Fp>\n\u003Col>\n\u003Cli>128+ players with regular gatherings\u003C\u002Fli>\n\u003Cli>The game server is CPU-bound and hitching, resources cannot be fixed in time, and you want voice out of that process now\u003C\u002Fli>\n\u003Cli>You use a tunnel-style DDoS proxy and want voice to reach players directly\u003C\u002Fli>\n\u003Cli>The game server is abroad but you want voice on a machine close to the players for low ping\u003C\u002Fli>\n\u003Cli>500 players or more: do not wait for symptoms, split on launch day\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>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).\u003C\u002Fp>\n\u003Ch3 id=\"setup-in-10-minutes-docker\">Setup in 10 minutes (Docker)\u003C\u002Fh3>\n\u003Cp>On the voice machine (Linux, port 64738 TCP+UDP open):\u003C\u002Fp>\n\u003Cpre>\u003Ccode>docker run -d --name mumble --restart unless-stopped \\\n  -p 64738:64738\u002Ftcp -p 64738:64738\u002Fudp \\\n  -e MUMBLE_CONFIG_USERS=2200 \\\n  -e MUMBLE_CONFIG_BANDWIDTH=48000 \\\n  -e MUMBLE_CONFIG_OPUS_THRESHOLD=0 \\\n  -e MUMBLE_CONFIG_MESSAGE_LIMIT=999999 \\\n  -e MUMBLE_CONFIG_MESSAGE_BURST=999999 \\\n  -e MUMBLE_CONFIG_WELCOME_TEXT=&quot;&quot; \\\n  -v mumble-data:\u002Fdata \\\n  mumblevoip\u002Fmumble-server:latest\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>The values that matter (with a package install, put the lowercase names in \u003Ccode>murmur.ini\u003C\u002Fcode>):\u003C\u002Fp>\n\u003Cdiv class=\"table-scroll\">\u003Ctable>\n\u003Cthead>\n\u003Ctr>\n\u003Cth>Setting\u003C\u002Fth>\n\u003Cth>Why\u003C\u002Fth>\n\u003C\u002Ftr>\n\u003C\u002Fthead>\n\u003Ctbody>\n\u003Ctr>\n\u003Ctd>\u003Ccode>users=2200\u003C\u002Fcode>\u003C\u002Ftd>\n\u003Ctd>The default is \u003Cstrong>100\u003C\u002Fstrong>. Player 101 gets no voice and no error on the game side. Always set it above \u003Ccode>sv_maxClients\u003C\u002Fcode> (2,048 slots → 2200)\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>\u003Ccode>bandwidth=48000\u003C\u002Fcode>\u003C\u002Ftd>\n\u003Ctd>Per-user bitrate cap in bits per second. Default 72000. Large servers use 48000 to bound total upload; small servers with spare port can use 72000–96000\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>\u003Ccode>opusthreshold=0\u003C\u002Fcode>\u003C\u002Ftd>\n\u003Ctd>Force Opus for everyone, never fall back to older codecs\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>\u003Ccode>messagelimit\u003C\u002Fcode> \u002F \u003Ccode>messageburst\u003C\u002Fcode>\u003C\u002Ftd>\n\u003Ctd>Newer Mumble rate-limits control messages per second. pma-voice changes voice targets very often as players walk around; the defaults cause audio to drop out in bursts\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003C\u002Ftbody>\n\u003C\u002Ftable>\n\u003C\u002Fdiv>\n\u003Cp>Then in the game server's \u003Ccode>server.cfg\u003C\u002Fcode>:\u003C\u002Fp>\n\u003Cpre>\u003Ccode>setr voice_externalAddress &quot;203.0.113.10&quot;   # public IP of the voice machine\nsetr voice_externalPort 64738\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Restart \u003Ccode>pma-voice\u003C\u002Fcode>, 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.\u003C\u002Fp>\n\u003Cp>Note: SaltyChat and TokoVoip run on TeamSpeak, not Mumble. This post applies to pma-voice and mumble-voip only.\u003C\u002Fp>\n\u003Ch2 id=\"admin-checklist\">Admin checklist\u003C\u002Fh2>\n\u003Cpre>\u003Ccode># server.cfg\nsetr voice_useNativeAudio true\nsetr voice_useSendingRangeOnly true\nonesync_distanceCullVehicles true\n# pma-voice\u002Fconfig.lua\nCfg.voiceModes = { {2.5, &quot;Whisper&quot;}, {6.0, &quot;Normal&quot;}, {14.0, &quot;Shouting&quot;} }\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cul>\n\u003Cli>Firewall: \u003Ccode>30120\u003C\u002Fcode> TCP+UDP (and \u003Ccode>64738\u003C\u002Fcode> TCP+UDP if voice is split)\u003C\u002Fli>\n\u003Cli>Radio channels of 20–30 at most, split per unit\u003C\u002Fli>\n\u003Cli>Push-to-talk in the server rules\u003C\u002Fli>\n\u003Cli>No \u003Ccode>server thread hitch warning\u003C\u002Fcode> in the console at peak hours\u003C\u002Fli>\n\u003Cli>Host: dedicated port, DDoS filtering at the network edge, not a tunnel\u003C\u002Fli>\n\u003Cli>128+ players, or any of the four conditions above, before splitting to an external Mumble; from 500 players split on day one\u003C\u002Fli>\n\u003Cli>1,000–2,048 players: game machine 2.5–10 Gbps dedicated, separate 1 Gbps voice machine, \u003Ccode>users=2200\u003C\u002Fcode>, \u003Ccode>bandwidth=48000\u003C\u002Fcode>, 6 m speaking range, radio channels capped at 30–40\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2 id=\"faq\">FAQ\u003C\u002Fh2>\n\u003Cp>\u003Cstrong>Can I change the bitrate of the built-in Mumble?\u003C\u002Fstrong> No server-side setting; FiveM uses its own mid value. To cap it you need an external Mumble and \u003Ccode>bandwidth\u003C\u002Fcode>.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>1–2 seconds of delay but no gaps?\u003C\u002Fstrong> TCP fallback almost every time. Check the server's UDP firewall first, then the player's VPN and router.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Just use Discord instead?\u003C\u002Fstrong> As a temporary fallback when the server is down. You lose positional audio and radio; RP without distance gets stale fast.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>pma-voice or SaltyChat?\u003C\u002Fstrong> 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.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Still choppy after splitting voice?\u003C\u002Fstrong> 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.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Can one Mumble server take 2,000 players?\u003C\u002Fstrong> 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 \u003Ccode>messagelimit\u003C\u002Fcode> throttling pma-voice's voice-target updates. pma-voice connects to a single \u003Ccode>voice_externalAddress\u003C\u002Fcode>, so voice cannot be sharded across machines; one machine has to be strong enough.\u003C\u002Fp>\n\u003Cp>Want the team to go through your config, hitching resources and host together: \u003Ca href=\"\u002Fen\u002Fservices\u002Fserver-setup\u002F\">FiveM server setup service\u003C\u002Fa>. For joining and map problems see \u003Ca href=\"\u002Fen\u002Fblog\u002Ffivem-stuck-loading-screen\u002F\">FiveM stuck on loading\u003C\u002Fa> and \u003Ca href=\"\u002Fen\u002Fblog\u002Ffivem-map-not-loading\u002F\">FiveM map not loading\u003C\u002Fa>.\u003C\u002Fp>\n",[23,29,34,39],{"slug":24,"title":25,"description":26,"date":27,"updated":28},"open-fivem-server-budget","How Much Does It Cost to Open a FiveM Server, and What Do You Need? From 32 Players to a 2,000-Player City (2026)","The essential scripts to launch a FiveM server in 2026 with budgets at three scales: starter 32–64, public 128–500, and a 1,000–2,048-player city (Element Club Platinum, dedicated hardware, separate voice and database, staff). Which parts free scripts cover, which are worth paying for, and which must be rewritten once you reach two thousand players.","2026-09-15","2026-10-14",{"slug":30,"title":31,"description":32,"date":33,"updated":20},"fivem-phone-death-screen","Free FiveM phone for ESX plus a death screen with Call EMS: the whole medic loop in two scripts","A free FiveM ESX phone script (X3D Phone: pma-voice calls, SMS with GPS sharing, dispatch, bills, banking, self-hosted camera, Buzz, Dark Chat) and the X3D Respawn death screen (Call EMS, wait-for-medics, death summary) that chain into one medic loop, with install steps and esx_ambulancejob compatibility.","2026-09-25",{"slug":35,"title":36,"description":37,"date":38},"fivem-server-hosting-rent","Renting a FiveM server host: VPS, dedicated or game panel, specs by player count, rough prices and a checklist before you pay (2026)","A 2026 guide to FiveM server hosting: machine rent vs slot fees (Element Club), how many players are free, the specs that matter most (single-thread CPU, NVMe, DDoS protection), rough specs from 32 to 2,048 players, game panel vs VPS vs dedicated, approximate monthly prices, and a 9-point checklist before paying.","2026-10-07",{"slug":40,"title":41,"description":42,"date":43,"updated":20},"fivem-map-not-loading","FiveM map not loading, falling through the map, buildings missing: causes and fixes for players and servers","FiveM falling through the map, map not loading, buildings and roads missing, spawning at (0,0,0) or dead. The real causes: slow HDD, low RAM\u002FVRAM, graphics mods, NPC overload, a core that saves corrupt coordinates on disconnect. Fixes for each, plus the free scripts that fix the server side.","2026-09-24",[],{"site":46,"contact":48,"seo":49,"payment":50},{"name":5,"host":6,"default_locale":7,"locales":47},[7,9],{"discord_invite":11,"email":12,"line":12},{"google_site_verification":12,"bing_site_verification":12},{"bank_name":12,"account_name":12,"account_no":12,"promptpay_id":12},[],1792316317540]