Jamulus: a jam server that mixes everyone's audio and sends it straight back

Everyone's audio, summed, returned to everyone

Jamulus enables musicians to perform in real-time together over the internet. The mechanism is described in one sentence in the project documentation, and that sentence is the whole architecture: a Jamulus server collects the incoming audio data from each Jamulus client, mixes that data and then sends that mix back to each client.

That is a centralised mixer, and the consequences follow directly. Every participant streams their own audio to the server, and every participant receives the sum of everybody's audio, not just one unidirectional feed. You hear the other players, and they hear you, in one shared mix, and the mix is identical for everyone because it is computed in one place.

The documentation claims that Jamulus can support large numbers of clients with minimal latency and modest bandwidth requirements. The two claims come from the same design decision. Latency is low because the client is not trying to synchronise with peers directly, it is just sending and receiving at a server with a known delay. Bandwidth is modest because the audio is compressed with the Opus codec, and because a client sends one stream and receives one stream regardless of how many other people are in the session.

The audience is musicians and music teachers, and the application areas in the project description are internet jam sessions, online jamming, and low latency audio. It is worth being clear at the outset that this is a performance tool, not a conferencing tool. The output is a mix, and the mix is the product.

The audio stack is Qt, Opus, and one important piece of borrowed reverb

The implementation is C on top of the Qt framework, and the project states it plainly: it is based on the Qt framework and uses the OPUS audio codec.

The platform support is specific about the audio interfaces. On Windows it runs under ASIO or JACK, on macOS under Core Audio, and on Linux under JACK. The ASIO mention comes with a trademark note in the acknowledgements, because ASIO is a trademark and software of Steinberg Media Technologies GmbH.

The acknowledgements section is the most revealing part of the documentation, because it shows what the project borrows. Besides Qt and the Opus codec, Jamulus contains audio reverberation code by Perry R. Cook and Gary P. Scavone from 1995 to 2004, taken from the Synthesis ToolKit in C++, and the JACK Audio Connection Kit by the JACK authors. Some pixmaps come from the Open Clip Art Library, and the country flag icons are from Mark James.

That reverb code is worth a second look. A server that mixes many voices benefits from a shared reverberant space, and a physically motivated reverb model from a synthesis toolkit gives the session a shared room rather than a dry sum. It is also the kind of dependency that has to be kept working when the platform underneath changes, and the project keeps `COPYING` in the root for exactly that reason.

The source tree is organised by platform, with `android/`, `ios/`, `linux/`, `mac/` and `windows/` directories beside the shared `src/`, plus `libs/` for the vendored libraries and `tools/` for developer utilities.

Two release lines are shipping at once

The release history is the most useful thing in the metadata for a new user, and it shows two lines running in parallel.

Version r3_12_5 was published on 2026-08-31, and on the same day r4_0_0beta3 was published, with r3_12_4 on 2026-08-09 before that. The last push to the repository was on 2026-10-16.

So the 3.12 series is the maintained stable line, and 4.0.0 is in beta, with a third beta already published. The tag naming convention encodes this: `r3_12_5` for a 3.12 release and `r4_0_0beta3` for the third 4.0 beta. The two being published on the same day is not a coincidence, it is the project cutting the stable fix and the next major from the same tree.

For an evaluator, the question this raises is compatibility across the two lines, and the repository does not answer it in the readme. The `ChangeLog` at the root is the place to look, along with `docs/` and the discussion forums.

The other maintenance signals are the presence of a `SECURITY.md`, a `CONTRIBUTING.md`, a `COMPILING.md`, an `AGENTS.md` for tooling support, a `.weblate` directory for translations, a `.pylintrc` and a `.clang-format` with a `.clang-format-ignore`.

There is also an `APPLEAPPSTORE.LICENCE.WAIVER` file at the root, which is a small but significant detail for a GPL application that wants to exist on iOS.

The build is qmake, with per platform directories

Jamulus is built with Qt, and the build system in the repository reflects that. The `Jamulus.pro` file at the root is a qmake project file, which is the older of the two Qt build approaches, and the platform directories carry the platform specific pieces.

The instructions for building are not in the readme, which links to `COMPILING.md` instead, and the same pattern is used for installation, where the readme points at the Getting Started page on the project wiki for instructions per platform. This is a sensible division for a project that supports three desktop platforms plus Android and iOS, because a single build document would be longer and would rot faster than a wiki page per platform.

The `android/` and `ios/` directories are the interesting ones for anyone assessing the reach of the project. A GPL application on the Apple App Store is a licensing problem rather than a technical one, and the `APPLEAPPSTORE.LICENCE.WAIVER` file at the root is the mechanism for addressing it. Jamulus is also a real-time network application, and the App Store has its own expectations about what an application may do with the network and the microphone.

For a Linux user, the `linux/` directory and the `libs/` tree are where the JACK and Qt dependencies are handled, and `tools/` holds the helper scripts.

Where Jamulus is the wrong tool

There are two kinds of wrong here, and it is worth separating them.

The first is a use case mismatch. Jamulus is for people performing together. A meeting, a podcast, a voice call, a music listening session: none of these fit, because the mixing model means you always receive the sum of the session and you always send your own audio to everyone. A tool that records one performer and sends it to many listeners is a different product, and using Jamulus for it means paying the bandwidth of a full duplex session for a one way need.

The second is operational, and it is about the network rather than the software. Real time musical performance needs a connection whose jitter and packet loss the codec can hide, and the client needs a low latency audio path, which on Linux means JACK and on Windows means ASIO or JACK. A musician on a hotel wifi, or a school that locks down the local ports, will not have a good session, and no configuration in the server changes that.

There is also the operational requirement of a server. One participant, or the server operator, has to run the server, and that machine's bandwidth has to cover every client it is sending a mix to. The documentation's claim of supporting large numbers of clients with modest bandwidth is about each client, not about the server, and a deployment plan has to account for the server side separately.

And the release line is a real cost. With a stable 3.12 series and a 4.0.0 beta running in parallel, the question of whether a plugin, a configuration file or a client build from one line works with the other is one the readme leaves open.

GPL terms, third party code, and the App Store waiver

The licence is the part to read carefully rather than assume.

The readme states that Jamulus is free and open source software licensed under the GPL, and it links the GNU GPL version 2 page. The repository's own metadata, however, lists the licence as a custom one that GitHub cannot classify, with a pointer to the `LICENSE` file. There is a `COPYING` file in the root as well, which is where the third party code licences are collected.

For a GPL application, the interesting legal question is not the licence of the project's own code, which is the GPL, but what happens to a modified build. The `APPLEAPPSTORE.LICENCE.WAIVER` file at the root is the answer to that for one distribution channel: the GPL has an exception mechanism for App Store distribution, and this file is where the waiver is recorded. The practical consequence is that iOS distribution is possible, and the file is what makes it possible.

The acknowledgements give the third party position clearly. The code is built on Qt, on the Opus codec, on JACK, on reverb code from the Synthesis ToolKit by Perry R. Cook and Gary P. Scavone, with some pixmaps from the Open Clip Art Library and country flag icons by Mark James. Each of those comes with its own licence, and a distributor of a Jamulus build inherits the obligations attached to them.

For a server operator, the one thing to check is the licence file itself, and the second thing to check is the waiver if you intend to ship a modified iOS build, since that is where the GPL is hardest to satisfy and where the project's own paperwork exists.

Editorial conclusion

Jamulus fits a band, an orchestra or a choir that wants to rehearse together from different places, and a music school that needs a session with people far apart, provided every participant can get a decent connection and one person can run a server. It does not fit a meeting, a podcast, or any use case where the point is to transmit one recording rather than let everyone hear each other live, because the mixing model assumes everyone wants the sum. It is also the wrong tool if you cannot accept the two-release-line situation, since a stable 3.12 series and a 4.0.0 beta are shipping at the same time. Before you deploy a server, read the Getting Started page for your platform and check the ChangeLog for the 4.0 transition, and note that the licence needs reading in the LICENSE file, since the metadata does not classify it.

Frequently asked questions

Official sources

1. Issues
2. jamulussoftware/jamulus on GitHub
3. Project website
4. README
5. Releases