Server-side AMBE vocoder: digital DMR audio without a dongle

Category: BasicsDifficulty: ★★☆~9 minutes

When people say "DMR voice is digital," there is a specific codec behind that statement — AMBE+2. Understanding how it works and why it is hard to "befriend" with a phone explains half of the architectural decisions in any modern network. Let's break it down, no fluff.

What a vocoder is and why AMBE+2

A vocoder is a speech codec: it compresses voice into a very narrow stream (in DMR that's about 2.45 kbit/s of useful data plus error protection). DMR uses AMBE+2 from the company DVSI. The radio digitizes your voice into AMBE, sends just a few bytes per frame (20 ms) over the air, and on the receiving end another vocoder expands it back into sound. This is exactly why DMR is robust against interference and frugal with spectrum — a comparison of the modes and their vocoders is in the DMR/D-STAR/C4FM/NXDN breakdown.

Why "translate" audio at all

Between two radios there is nothing to translate: both speak AMBE, and the stream stays compressed from end to end. The problem appears when you need to bring something non-DMR into the network:

an app on a phone — the microphone produces ordinary PCM, which has to be encoded into AMBE to get on the air, and AMBE has to be decoded for playback;
a SIP phone / telephone line — there you have G.711 or Opus, which also need conversion;
recording and voice services (announcements, echo test) — the server needs to "understand" the audio.

This PCM ⇄ AMBE operation is called transcoding, and it is the vocoder that does it.

Why a dongle used to be needed

AMBE+2 is proprietary and patented (DVSI). For a long time the only "honest" way to get AMBE from arbitrary audio was a hardware AMBE dongle — a USB stick with the proprietary chip. One dongle handles one or two voice streams; for a network with dozens of users that turns into a rack of dongles and a tangle of cables. That is exactly why many projects steer clear of phone/SIP altogether: "expensive and bulky."

Where the "zoo" hides Chains like "DMR ↔ Analog_Bridge ↔ dongle ↔ SIP" do work, but they are a stack of intermediaries: separate services, separate hardware, separate points of failure. The fewer of them, the more stable the network.

A software vocoder on the server

There are software implementations of the MBE/AMBE vocoder (open-source, based on the mbelib library and related ones) — they encode and decode AMBE+2 purely in software, without a chip. If you put such a vocoder on the server next to the master, something important happens:

the phone sends PCM → the server encodes it into AMBE → the frames go on the air as if from an ordinary radio;
the air (AMBE) → the server decodes it → the phone hears the audio;
no dongles: one server handles many streams and scales in software.

It is precisely the server-side vocoder that makes possible a radio in a smartphone, a telephone bridge, recording and announcements — without the hardware zoo. In DMRhub it is used as a standard component, and we keep its source code open.

About patents — honestly The AMBE+2 algorithm itself is patented by DVSI; software implementations are independent (clean-room) code. For amateur-radio and research use this is common practice, but for a commercial product the patent risks should be assessed separately.

In short A vocoder is a "translator" between ordinary audio and the compressed AMBE+2 of the air. This used to require a dongle; now a software vocoder on the server is enough — and the network gains a phone, an app and voice services without intermediaries. Related: how the network is built and bridges between networks.