If you've ever wondered how a DMR talkgroup ends up linked to an AllStarLink node, or how a P25 reflector can talk to a Fusion room, the answer is almost always DVSwitch. It's the toolkit that bridges one digital voice world to another — and to the analog world too. It can look intimidating because it's not a single program but a small family of cooperating tools. The trick to understanding it is to stop thinking of it as one big machine and start seeing it as a pipeline — a stream of audio passed hand to hand, one transformation at a time.
The DVSwitch authors describe themselves as "widget makers." Each tool does one job, has a defined input and output, and connects to the next tool over a simple UDP link. You don't configure "DVSwitch"; you stand up two or three of its widgets and point them at each other to form whatever bridge you need. Once you grasp the pipeline idea, the long config files stop being mysterious — they're just describing which port hands off to which.
This is the piece that speaks to the digital voice networks. It's a stripped-down, modem-less version of Jonathan Naylor's (G4KLX) MMDVMHost — the same software that runs hotspots, but with the radio hardware removed. Instead of a modem, it connects over the internet to DMR, YSF, P25, NXDN, D-STAR, or M17 networks and reflectors, behaving exactly like a hotspot would. On one side it talks the mode's network protocol; on the other it hands the compressed voice frames to Analog_Bridge.
Analog_Bridge (which began life as the old DMRGateway/ambe_audio) is where the real conversion happens. Its whole job is to move between two worlds: compressed digital voice (AMBE/IMBE frames) on one side and plain PCM audio on the other. To do that it needs a vocoder to actually crunch the codec math.
Analog_Bridge gets its codec muscle one of two ways. With hardware, it talks to AMBEserver, a small program that shares AMBE dongles (a ThumbDV, DVStick 30, or DVStick 33) over a network socket so the bridge can reach them. With software, it can fall back to md380-emu, an AMBE+2 vocoder emulator — handy, but only for the AMBE+2 modes, never for D-STAR's older codec. (This is the same codec-hardware story told in the XLX reflector guide.)
The "plain PCM" side of Analog_Bridge speaks USRP, a simple protocol borrowed from AllStarLink's chan_usrp driver. It carries uncompressed 8 kHz, 16-bit audio plus push-to-talk signaling over UDP. USRP is what lets Analog_Bridge connect to AllStarLink or EchoLink — or to another Analog_Bridge, which is the key to digital-to-digital bridging below.
Here's the insight that ties the whole system together. DVSwitch never converts one digital codec directly into another. Instead, every stream is decoded down to plain PCM audio in the middle, and then re-encoded into whatever it needs to become on the far side. PCM is the universal meeting point — the common language every mode is translated through.
That's why building an analog-to-digital bridge takes one Analog_Bridge, but a digital-to-digital bridge takes two, sitting back to back with USRP audio flowing between them:
Translating through PCM is what gives DVSwitch its superpower: because every mode reduces to the same plain audio, anything can bridge to anything — DMR to P25, NXDN to AllStar, Fusion to EchoLink, in any combination. The cost is vocoders. Every digital leg of the chain needs codec horsepower (a hardware channel or a software emulator) to get into and out of PCM, so a busy multi-mode bridge can consume a fair number of vocoder channels. It's the same trade-off the transcoding reflectors face, just expressed as a pipeline instead of a server.
| Audio type | Codec | Modes that use it |
|---|---|---|
| AMBE | AMBE+2 (ambe3600x2450) | DMR, NXDN, Fusion (narrow / DN) |
| IMBE | IMBE (imbe7200x4400) | P25, Fusion (wide / VW) |
| DSAMBE | AMBE (ambe3600x2400) | D-STAR (its own, older variant) |
Analog_Bridge knows how to decode and re-encode each of these to and from PCM, which is exactly why DVSwitch can bridge across them — and why D-STAR, with its odd-one-out codec, still insists on hardware.
DVSwitch isn't a replacement for the reflector and gateway software you've met elsewhere on this site — it's the connective tissue between them. MMDVMHost runs your hotspot; HBlink3 builds a DMR network; the DMR Gateway lets one hotspot reach several DMR networks. DVSwitch is what you reach for when you need to carry audio across modes — to glue the digital world to AllStarLink, or to weld two different digital modes together that have no native way to talk.
The N6JET 6-Link — the cross-mode fanout that ties all the digital voice modes together — is built on exactly this architecture: MMDVM_Bridge instances reaching each network, Analog_Bridge instances meeting at PCM over USRP, and AMBE hardware (served by AMBEserver) doing the transcoding. Seen through the pipeline lens, a daunting multi-mode bridge is just the same two-widget pattern repeated and fanned out.
DVSwitch is a set of small, single-purpose tools you chain together: MMDVM_Bridge talks to the digital networks, Analog_Bridge converts between compressed voice and plain PCM, a vocoder (AMBEserver hardware or md380-emu software) does the codec work, and USRP carries the plain audio to AllStar or to another bridge. Everything meets in the middle as PCM, which is why it can connect anything to anything — and why every digital leg pays for a vocoder. Think pipeline, one transform at a time, and the whole thing comes into focus.