vban: command line tools for the VBAN audio protocol on Linux

Three tools, and the protocol is a simple one

vban is an open-source implementation of the VBAN protocol, which is a simple audio over UDP protocol proposed by VB-Audio. The project is described as composed of several command-line tools, and three are named with their jobs. vban_emitter streams audio coming from audio backend interfaces to a VBAN stream, vban_receptor plays an incoming VBAN stream out to audio backend interfaces, and vban_sendtext sends text over the vban protocol. The copyright line in the readme is 2015 Benoît Quiniou, and the project is licensed GPL-3.0 with a COPYING file at the top level. What makes the protocol attractive for this kind of tool is that it is a single stream over UDP with a stream name and a channel count, so the tools are thin: one process reads or writes a local backend, and the other end is another process on another machine. The trade is that UDP is not reliable and there is no reordering guarantee, which is why the quality setting exists.

The build is autotools, and the backends are compile time choices

vban is distributed with autotools build scripts, so building requires autoconf and automake, and the sequence is the familiar one.

	$ ./autogen.sh              # probably only once for ever
	$ ./configure               # with or without options (--help to get the list of possible options)
	$ make                      # with or without options

To install, you invoke make install. The configure step matters more here than in most projects, because by default the tools are compiled with all three audio backends, and the ones you do not want can be turned off with dedicated options, --disable-alsa, --disable-pulseaudio and --disable-jack. Since the relevant development libraries have to be present at configure time, disabling the unused ones is what lets you build on a machine that only has one audio stack installed. The readme names the usual package names for each: libasound and libasound-dev for Alsa, libpulse and libpulse-dev for PulseAudio, and libjack and libjack-dev for Jack. The repository also carries a CMakeLists.txt alongside the autotools files, so both build systems are present, plus a Makefile.am and a configure.ac and an autogen.sh script.

Backends beyond the three obvious ones, including a pipe

The supported output targets are more interesting than the list of libraries suggests. Alsa, PulseAudio and Jack have been implemented for the audio tools, and there is also a fifo, meaning a pipe, output, which exists to allow chaining command line tools, and a file output that writes raw PCM data. The pipe target is the reason the tools are described as chainable, and it turns the set into something composable: a receptor writing to a pipe and an emitter reading from one lets you process a stream in the middle without any of the pieces knowing about each other. The file output is a plain raw PCM capture, which is useful for recording a remote stream or for feeding a stream into something that wants a file. The backends are chosen at runtime with the -b option, and the readme lists the available types as alsa, pulseaudio, jack, pipe and file, with alsa as the default.

The receptor and emitter take the same three mandatory arguments

Invoking vban_receptor or vban_emitter with no parameter gives you the usage hints, and the readme prints them in full. Both tools require an address, a port and a stream name, and they are marked MANDATORY in the help text, so a session is defined by where the audio goes, which port carries it and what it is called. The receptor adds a backend, a device name, a quality indicator and a channel list, and its help marks -o as DEPRECATED in favour of -d, which is the device. The emitter adds the audio format side: the sample rate defaults to 44100, the number of channels defaults to 2 and the sample format defaults to 16I, with the recognized bit formats listed as 8I, 16I, 24I, 32I, 32F, 64F, 12I and 10I. Both take a log level from 0 for FATAL to 4 for DEBUG, defaulting to 1 for ERROR, and the emitter's backend option is marked TEMPORARY DISABLED with a note that only the Alsa backend is working at this time.

Channel selection, and the sendtext tool that drives VoiceMeeter

The channels option is the feature that makes vban more than a pipe for sound. The help describes a list of the form x,y,z, with the default being to forward the stream as it is, and the readme adds three tips. Channel indexes run from 1 to 256 as specified by the VBAN specifications, which it says is probably enough for any soundcard or Jack configuration. You can repeat channels, which is how one source is spread across several outputs. And if you use channels that do not exist, you get silence but no error, which is a genuinely useful property for a tool that has to keep a fixed output configuration while the remote side changes. The examples show the shape.

	vban_receptor -i IP -p PORT -s STREAMNAME -c1                   # keep only channel 1 and play out as mono
	vban_receptor -i IP -p PORT -s STREAMNAME -c1,1,1,1             # keep only channel 1 and play it out on 4 output channels (given that your output device is able to do it)
	vban_receptor -i IP -p PORT -s STREAMNAME -c2,41,125,7,1,45     # select some channels and play them out on 6 output channels (same comment)
	vban_emitter -i IP -p PORT -s STREAMNAME -c1,1,1,1               # use audio source channel 1 (opening it in mono therefore, and build up a 4 channels stream with copies of the same data in all channels)
	vban_sendtext -i IP -p 6980 -sCommand1 "Strip(0).mute = 1;"     # mute strip 1 of VoiceMeeter Banana. see [VoiceMeeter Banana manual](https://www.vb-audio.com/Voicemeeter/VoicemeeterBanana_UserManual.pdf) for more info

vban_sendtext is the odd one out and the most interesting, because it turns a VoiceMeeter Banana instance into something a script can control. The example mutes strip 1 with a Strip(0).mute command over the text protocol.

Latency is a buffer size you choose, and there is no GUI here

The latency section explains that the receptor does its best to keep latency reasonable according to the -q quality parameter, and that a buffer size is computed from that parameter following the recommendation of the VBAN protocol specification document. The consequences differ per backend. Data is read from and written to the network in chunks of that buffer size. For Alsa, the buffer size is used to require an adequate latency. For PulseAudio, it is used directly to set the stream buffer size. For Jack, it is used to set an internal buffer size to the double. So the same number means different things on different stacks, and the quality value is not a portable latency promise. The project is only composed of command line tools, and the readme is direct about it: if you are looking for a GUI, the VBAN-manager project on GitHub is the place to look. The two releases published on the same day in April 2026, v2.2.0 and v2.1.0, and the last push to the repository on 2026-04-03, suggest the current line is the maintained one.

Editorial conclusion

vban fits a Linux user who needs to move audio between machines with VoiceMeeter or a similar host, particularly one who wants a command line tool with selectable channels rather than a routing GUI, since the receptor can pick individual channels out of a multi channel stream and play them on as many outputs as the device allows. It does not fit a macOS or Windows user, because the project is Linux only, and it does not fit someone who needs a graphical mixer, because the readme points to a separate VBAN-manager project for that. Before you build it, decide which backends you actually need so you can disable the rest at configure time, check the -q quality setting against your latency tolerance, and note that the emitter's backend selection is temporarily disabled and only Alsa works there.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. quiniouben/vban on GitHub
4. README
5. Releases