voice_useSendingRangeOnly Explained for PMA-Voice

voice_useSendingRangeOnly is a FiveM voice convar that limits hearing to clients within their sending range when enabled.

For the current standard PMA-Voice configuration, use:

setr voice_useSendingRangeOnly false

That is also the value generated by FiveMesh Voice. It allows PMA-Voice to manage proximity, radio, call and other voice targets without an additional sending-range filter interfering with that logic.

Current PMA-VoiceRecommended pathSet falseAvoid the extra sending-range-only filter.PMA-Voice targetsProximity, radio and calls manage the intended listeners.

Custom voice resourceVerify its own documentationCheck the resourceDo not copy PMA-Voice settings into a different system blindly.Test every modeVerify proximity, radio, calls and other long-range targets.

What the convar does

The Cfx.re voice documentation describes voice_useSendingRangeOnly as a convar that limits hearing to clients within their range. Its default value is false.

That sounds simple, but a full voice resource does more than proximity chat. PMA-Voice also manages radios, calls and explicit voice targets that are meant to work outside normal proximity.

If an extra range filter is enabled while PMA-Voice is managing those targets, the two layers can disagree about who should be heard. That is why the current PMA-Voice server code warns when voice_useSendingRangeOnly is set to true.

Why older advice can look contradictory

Voice configuration examples have changed over time, and search results often mix FiveM's general voice behavior with PMA-Voice-specific guidance.

You may find an old configuration, a custom fork or a forum answer that recommends true. That does not mean the advice matches the PMA-Voice version and integrations running on your server today.

For current PMA-Voice, use the project's active source as the reference:

• The PMA-Voice manifest declares false for this option.
• The PMA-Voice server startup code warns when it detects true.
• FiveMesh Voice generates false in its PMA-Voice setup block.

If you operate a fork, inspect that fork rather than assuming it behaves exactly like the upstream project.

Where to place the setting

Define the value once in the server-side configuration used by the intended FXServer instance:

setr voice_useNativeAudio true
setr voice_useSendingRangeOnly false

ensure pma-voice

Keep voice convars together and place them before ensure pma-voice so the active configuration is easy to review before the resource starts.

Search nested configuration files, hosting-panel settings and environment-specific files for another definition. A later setr voice_useSendingRangeOnly true can overwrite the value you expected to use.

Fix the voice_useSendingRangeOnly warning

If PMA-Voice prints a warning about this convar:

1. Search every executed configuration file for voice_useSendingRangeOnly.
2. Remove duplicate or conflicting definitions.
3. Set the current PMA-Voice value to false once.
4. Restart through your normal deployment process.
5. Confirm the warning is gone.
6. Test proximity, radio and calls with at least two players.

Do not stop at the missing warning. The configuration is only verified when the voice modes your server actually uses still work.

What this setting does not fix

voice_useSendingRangeOnly is not a general voice repair switch.

Changing it will not fix:

• A blocked external Mumble port.
• An incorrect voice_externalAddress or voice_externalPort.
• Two voice resources running at the same time.
• A radio or phone integration that assigns the wrong channel.
• One player's microphone, input device or network connection.
• CPU pressure, packet loss or a voice endpoint placed far from the community.

If the symptom is robotic, stuttering or completely missing audio, use the PMA-Voice troubleshooting guide to identify whether the problem affects one player, one integration or everyone.

Does external PMA-Voice change the value?

Not by itself.

An external voice setup changes the Mumble address and port used by players. PMA-Voice still manages the voice behavior on top of that endpoint, so the standard FiveMesh block keeps voice_useSendingRangeOnly false:

setr voice_useNativeAudio true
setr voice_externalAddress "your-voice-hostname"
setr voice_externalPort 43001
setr voice_externalDisallowJoin 0
setr voice_useSendingRangeOnly false

The external hostname should not include http:// or https://. It is a voice endpoint, not a web URL.

A practical test matrix

Use two or more players and verify each layer separately.

Test	Expected result
Nearby proximity	Players within the configured proximity can hear each other.
Outside proximity	Players outside the range do not hear normal proximity voice.
Radio	Players on the intended radio channel can communicate across distance.
Call	Participants in the same call can communicate across distance.
Unassigned player	A player outside the target does not hear the radio or call.
Restart	Voice reconnects with the same behavior after the normal restart flow.

If proximity works but radio or calls fail, inspect the integration and voice-target assignment before blaming the external host. If every mode fails, verify resource startup, endpoint reachability and shared configuration first.

Using FiveMesh Voice

FiveMesh Voice provides managed PMA-Voice-compatible infrastructure and generates the external address, port and convars for the selected server.

Keep the generated setup together and avoid changing one line without understanding which layer it controls. voice_useSendingRangeOnly false lets PMA-Voice manage its intended targets; the external address and port decide where the Mumble connection goes.

The useful rule is narrow: for current standard PMA-Voice, keep this setting false. For a different voice resource or custom fork, follow and test that resource's current configuration instead.