pma-voice

pma-voice is your server's voice layer: it owns the channels, the proximity and the state of who is talking to whom. Cube Radio does that same job, so running both leaves you with two systems fighting over the same voice control. This is not a conflict you configure away: you have to pick one.

We say it here, before the purchase, because it is the kind of detail that usually turns up in a support ticket at two in the morning. If your server depends on very specific integrations built on pma-voice, message us on Discord before buying and we will go through it with you.

What you gain is real radio infrastructure instead of abstract channels. The repeaters you declare in config have position, antenna height, range and terrain penalty, and line of sight to the antenna is actually sampled: drop into a canyon and you lose coverage, climb the ridge and it comes back.

Channels become server-side, with access control by job or by ACE. A client does not join a channel by claiming it can, and a channel it has no business in is never even sent to it. With no infrastructure the channels fall back to simplex, radio to radio at short range, so without a repeater you are not mute: you are local.

Device state (serial number, battery, volume, presets and scan list) lives in the database against your identifier, not in item metadata. That detail is the reason it behaves the same across every supported inventory.

Take stock of which of your resources call pma-voice exports: dispatch, voice HUD, faction radios or any script that forces a channel. Those are the points you need to repoint.

And test it on a development server first. Swapping the voice layer in production on a Friday night is the definition of a bad idea.