Mumble client · Windows · macOS · iOS · iPadOS · Android

Voice for bikers

A Mumble client built for wind and engine noise inside a helmet. Windows, macOS, iOS, iPadOS and Android.

Those bars are the app's own analyser: microphone, after suppression, and what actually leaves for the server.

Intercoms stop at the end of the group

A Bluetooth intercom pairs riders together and holds them within a few hundred metres of each other. Lose the group at a junction and you lose the conversation. MumbleWay puts the conversation on the internet instead: everyone joins the same Mumble channel over mobile data, and it makes no difference whether the next rider is a hundred metres ahead or in another country.

What it is not is a general-purpose voice app with a motorcycle icon. Every decision in the capture chain assumes a microphone a centimetre from your mouth, inside a helmet, at speed, with wind and an engine underneath.

Intercom range against an internet channel On the left, a Bluetooth intercom: two riders inside a dashed circle are connected, and a third who has fallen behind sits outside it, disconnected. On the right, the same three riders at the same distances all connect to a Mumble server, and the distances between them no longer matter. BLUETOOTH INTERCOM a few hundred metres out of range MUMBLEWAY your Mumble server a hundred metres, or another country
An intercom is a radio link between helmets, and it ends where the radio does. Putting the channel on a server you control removes distance from the problem — and replaces it with needing a signal, which is the trade this whole app is.
Range Anywhere

Mobile data, not a radio link between helmets.

Codec Opus

48 kHz, with forward error correction that rises as the link degrades.

Servers Yours

Any Mumble server. No account, no directory, no company in the middle.

What it does about noise

Speech from inside a helmet at speed is a hard signal. The chain is built for it, and every stage is visible while it runs.

How a block of sound gets from the helmet to the others A single row of stages, left to right: microphone, echo canceller, speech band, enhancer, blend, gate, level, restore, limiter, and out to the others. Solid arrows are the sound itself, which passes through every stage in that order. Dashed arrows underneath carry information rather than sound: the background level and the signal-to-noise ratio pick the profile and set the gate's threshold, a voice test decides whether the gate opens, and what the enhancer removed tells the restore stage what to put back. what the others are saying reference Microphone in the helmet Echo AEC3 Band speech only Enhancer DeepFilterNet 3 Blend by profile Gate with look-ahead Level automatic Restore on the voice Limiter always last To the others Opus, 20 ms Profile from the first second of speech Is this a voice? VAD, pitch, margin What the enhancer removed and in which band The background level, measured continuously the quietest it has been lately, not the average sound information first, or every later stage passes it last, or it is not a limiter The order is the code's own, not a tidied version of it.
Every sample takes the green path, in that order. The amber boxes are never heard: they are measurements taken off the signal that change how a later stage behaves. That distinction is worth holding on to when reading the diagnostics panel — the voice test removes nothing, it only decides whether the gate opens.
The same chain, in the three conditions it is built for Three rows, one per condition. Each shows what the microphone hears on the left and what the others receive on the right. Standing still, the background is a thin band and speech passes almost untouched. At speed, wind is a thick band that is gone from the transmitted side. At a stoplight beside running engines the band is thicker still and is also gone. The stages are identical in all three rows; only the profile differs, chosen from the measured signal-to-noise ratio. what the microphone hears what the others get Standing still, or indoors signal-to-noise above 35 dB Wind, at speed between 20 and 35 dB Engines, at a stoplight below 20 dB Light Standard Helmet background speech Same stages in all three. Only the profile differs.
Illustrative shapes rather than a measured capture: at this size a real one is a grey smear, and what matters here is which band the chain removes and which it keeps. Automatic picks the profile from the signal-to-noise ratio of the first second after the gate opens, and reconsiders when the background moves. The gaps inside a row are not the channel shutting — it holds open for a second, which is what stops one sentence arriving as three fragments.
How voice activation opens and closes the channel Three stacked tracks. The spoken word runs from 200 to 560 milliseconds. The detector only recognises it from 250 to 520, missing the first consonant and dropping before the last. What is transmitted runs from 200 to 720: a 240 millisecond look-ahead recovers the opening consonant, and a one second tail carries the closing one and bridges the gaps inside the sentence, fading over its final 30 milliseconds. You say Detector Transmitted s t speech detected on the wire 240 ms look-ahead 1 s tail 30 ms fade
A threshold decides mid-syllable. Holding the audio back by 240 ms lets the channel open on the sound that led into the decision, so the opening consonant survives; a one second tail carries the closing one, fading at the very end so it does not click.

When a phone cannot keep up

A block of audio arrives every 10 milliseconds, and the whole chain has to be finished before the next one turns up. On a current phone that is comfortable. On an outdated or entry-level one it is not, and the useful thing to do about that is not to pretend otherwise.

So the device is measured against the deadline when the app starts, before your first call, and watched while you talk. If it does not fit, stages are given up one at a time — in an order that was measured rather than guessed, and never quietly.

The speech enhancer is also timed on its own at that point, because it is the one stage large enough to decide the answer by itself. A phone where the model alone takes 4 ms of the 10 has no room for the seven stages behind it, whatever the total happens to say on a device that is not yet in a call — so it loads the cheaper model straight away, rather than working down through eleven other stages to arrive at the same place a conversation later.

What a slow device gives up, and in what order Eight steps descending from left to right. The speech enhancer softens first, then the look-ahead pay-down stops, then the echo canceller's filter halves, then three cheap detectors, then the diagnostics panel's own drawing, then its live dots and meters, then a cheaper noise model, and last of all the enhancer is switched off altogether. enhancer softens pay-down stops echo filter halves cheap detectors panel drawing live dots stop cheaper model enhancer off given up first given up last cheapest quality first
The order is measured, not guessed. The two cheapest things to give up are also the two largest savings, and the one that costs the most — the enhancer, which turns 1.5 dB of separation into 16 dB — is the last thing tried rather than the first.

The cheapest quality goes first. The enhancer softens by two steps before anything else is touched: they are the two largest savings on the chain and cost almost nothing, and on voice over music the first of them measured better than the full setting. Then the look-ahead stops being paid down, which changes no sample a listener hears — only the delay goes back up to what it was before that existed. Then the echo canceller’s filter halves, keeping the loud direct path and giving up about 10 ms of the tail behind it. Then three detectors whose work the level meter largely duplicates. Then the diagnostics panel’s own drawing, which is free to give up because nobody’s voice passes through it. Then the rest of the panel’s liveness — the moving dots and the per-speaker meters — for the same reason. Then a cheaper, more aggressive noise model. Switching the enhancer off is the thirteenth and last thing tried, because it is the one that turns 16 dB of separation between speech and gaps back into 1.5.

Below the ladder there is one thing left. If every stage above has gone and blocks are still late, the chain asks what is actually taking the time. Echo cancellation is the only stage whose cost is set by the other end of the call rather than by your phone — it does almost nothing while nobody else is talking — so on the rare device where that is what the blocks are going over on, its filter is shortened again, in steps, until it covers the loud direct path and nothing more. It is never switched off: on a loudspeaker that is a howl, and the guard that would have caught one went eleven stages earlier.

It does not climb back during a session. A device that was late once will be late again, and a chain that switched stages on and off as the load moved would sound worse than either state. Restarting the app tries the whole chain again.

And it tells you. Stages that have been given up are struck through in the diagnostics panel, the toolbar icon becomes an amber warning so you find out without going looking, and the panel says in plain words what was dropped and what it costs.

The diagnostics panel after the chain has been cut back: an amber
              warning in the toolbar, the analyser replaced by a note saying it
              was switched off, Suppressor, Feedback and Enhancer struck through
              in the stage list, the enhancer reading Off, and a warning saying
              that a more powerful device would run the whole chain.
The bottom of the ladder, and the panel saying so.

One thing worth knowing: this measures the device as it finds it, not as it could be. A computer that is busy with something else when the app opens can start a step lower than the same computer idle.

Watch how it works

Most voice apps tell you nothing. When somebody says “it cut me off”, there is no way to find out which stage cut them.

MumbleWay has a diagnostics panel with a live spectrum analyser showing three traces at once — microphone, after suppression, and what is actually being sent — with a light per stage of the chain. The sent trace going flat while the other two do not is the most useful thing it shows.

It can also record what the microphone heard along with what the chain decided about it, block by block, so a recording that cuts out can be examined rather than guessed at. That exists because a whole round of measurements was once invalidated by discovering the recordings behind them had come from the phone’s own microphone rather than the headset’s. Audio carries no record of what captured it; recording from inside the app makes it the chain’s own input by construction.

The diagnostics panel while speech is being detected: three traces,
              the transmitted one filled in, and the voice, gate and to-the-server
              lights all green.
Speech detected, and going out.
The same panel with no speech: the transmitted trace is flat, the
              legend reads Not sending, and the voice, gate and to-the-server
              lights are red.
No speech: the sent trace goes flat while the others do not.
The main screen on iPhone connected to a public server, showing
              the UDP round trip, who is in the channel, the channel list and
              the microphone meter.
Connected: latency, channel, and the meter.

On a desktop the same thing is a two-pane window: your servers down one side, the channel and who is in it down the other.

MumbleWay on Windows: saved servers on the left with latency and
         the UDP round trip, the channel and its members on the right, and
         the microphone meter along the bottom.
Windows, connected. The same app, given room.
The diagnostics panel on Windows: the analyser with the gate's
         opening level and noise floor marked across it, what the background
         sounds like and the profile that answer chose, the stage lights and the
         enhancer's rung, above four columns of counters for incoming audio,
         this device, where a block's ten milliseconds go, and the server.
The diagnostics panel, where a wide window shows every counter at once instead of stacking them.
MumbleWay on macOS, connected to a public server: the server card
              down the left showing its voice path as TCP tunnelled in amber,
              two people in the channel and the channel tree on the right, and a
              live microphone meter along the bottom.
macOS. This one says TCP rather than UDP — the network was not passing the voice port, and the app says so instead of quietly sounding worse.

Advantages

Range is not a constraint

Riders separated by traffic, a junction or a border stay in the same conversation. An intercom cannot do this at any price.

Your server, your rules

Any Mumble server will do, including one on a Raspberry Pi at home. There is no account to make and no directory your channel appears in.

More than two riders

A Mumble channel holds as many people as the server allows, without the chain-of-hops fragility that mesh intercoms have.

It shows its working

A live analyser, per-stage status, and recordings that carry the decisions alongside the audio.

Nothing is collected

No account, no analytics, no advertising, no telemetry. Audio is never stored unless you turn recording on yourself. See the privacy policy.

Free software

GPL v3, source in the open, and it speaks a documented protocol with other clients rather than one vendor's.

Disadvantages

Worth reading before you rely on it. These are real and none of them is going to be fixed by a setting.

No signal, no conversation

This is its defining weakness. An intercom keeps working in a valley, a tunnel or a dead spot; this does not. If your riding is mostly remote, an intercom is the better tool and this is a supplement to it.

It costs mobile data and battery

Roughly 3–6 MB per hour of talking on the wire, more with error correction on a poor link. A phone doing continuous voice over mobile data with the screen off still gets noticeably warmer than one that is not.

Latency is a network's, not a radio's

The capture chain contributes little — the look-ahead pays itself down to 200 ms — but the network does not, so expect a couple of hundred milliseconds on a good mobile link and more on a bad one, against near-zero for an intercom between two adjacent helmets. Conversation works; interrupting somebody mid-sentence does not land the way it does face to face.

Bluetooth costs you audio quality

A headset microphone is only reachable over the hands-free profile, which is mono and narrowband. While a call is up, music through the same headset drops to telephone bandwidth. That is a property of Bluetooth, not of this app, and every voice app on your phone has it.

You need a server

There is no MumbleWay service to sign up to. Someone in the group has to run a Mumble server or rent one — a deliberate choice, and still a step that an intercom does not ask of anybody. It takes about ten minutes.

Music can occasionally key the channel

This was the worst thing about the app and is now a footnote. Speech over your own music goes through 98% of the time where it used to be 63%, and the enhancer takes 19 dB out of the gaps between your words — music that used to sit a decibel and a half under the speech now sits sixteen under it. In riding since, music keys the channel only rarely, and what gets through arrives well down rather than at level.

It is not zero, and the reason it is not is worth knowing: the detector was trained to tell speech from noise, and music is neither. Push-to-talk removes the possibility entirely if you need certainty, and the work is documented in the open, including every attempt that has already failed.

Where to go next

Settings

What every setting does, and which ones actually matter on a bike.

On the road

Setups that work: a pair, a group, a passenger, a rally.

Your own server

Mumble server on Windows, macOS or Linux, in about ten minutes.