Wired vs Bluetooth Microphone Latency

A cable wins, and it is not close. A wired microphone's delay is too small for a person to hear, while an iPhone feeding a Bluetooth speaker sits at roughly 100 to 200 milliseconds. Wired vs Bluetooth microphone latency is a gap of about two orders of magnitude, and nothing in the phone's settings closes it.

The useful question is whether that delay matters for the job in front of you. For a lot of jobs it genuinely does not.

Three paths, one table

Three realistic paths get a voice out of a loudspeaker in a living room or a car park.

Those are starting points, not promises. The buffer inside a cheap speaker is nobody's published number. For your own figure instead of a table's, the site's Bluetooth latency test measures the real round trip through your own speaker: it plays a chirp, records it back through the microphone, cross-correlates the two over five runs and subtracts the flight time through the air.

Wired vs Bluetooth microphone latency: where the gap comes from

A cable has nothing in it to be slow with. The signal travels as voltage, and across a stage that time is far below anything an ear resolves. Wired microphone delay, where it exists, comes from what the cable is plugged into: a digital mixer's converters, or a powered speaker's DSP. Small, and fixed.

A Bluetooth link is a different animal. Audio is captured into a buffer, compressed into codec frames, packetised, sent over a shared 2.4 GHz band with retries when a packet is lost, held in the receiver's jitter buffer so a dropout does not become a click, then decoded and converted back to analog. That jitter buffer lives in the speaker, where you have no access to it, and it is often the largest single contributor to the total. On some links it is not the largest: the codec's own frame delay dominates instead, which is why two speakers on the same phone can measure so differently.

The codec sets the floor. Published figures for wireless microphone latency break down by codec:

• SBC: quoted as 100 to 150 ms by some sources and 150 to 300 ms by others. Those ranges barely overlap, and averaging them would invent a figure nobody measured.
• AAC: roughly 100 to 200 ms. This is the one that matters, because it is what an iPhone sends.
• aptX Low Latency: about 40 ms, per Qualcomm. An iPhone has no aptX support at all, in any variant, so it is a number you read about and never use.
• LC3 with LE Audio: about 20 to 30 ms, per the Bluetooth SIG. Both ends have to support it.

The codec-by-codec comparison with sources attached covers where each figure was published and why they disagree. If you were hoping a firmware update or a better app fixes this, read why an iPhone will not give you aptX Low Latency. No app can remove the delay, because the delay is not in the app.

Measure before you argue

Spec sheets describe a link. What you feel is the whole round trip: capture, encode, radio, buffer, decode, driver. A measured result often lands above the codec figure, and it is the one that decides whether your setup works.

Run the round-trip measurement on the speaker you actually own, where it will actually stand. A result near 100 ms and one near 300 ms are different products in practice, even if both are sold as "a Bluetooth speaker". On what those milliseconds feel like, the thresholds where delay becomes audible: under about 20 ms nothing registers, 40 to 50 ms is where lips and sound visibly part company, past about 100 ms it feels like a bad phone call. Hearing your own voice come back is far more sensitive than listening to someone else's.

The 2.4 GHz middle path

Between a cable and Bluetooth sits a category people forget: dedicated wireless microphone systems that use the 2.4 GHz band without using Bluetooth at all. A Rode Wireless GO II or a DJI Mic clips a transmitter to your collar and puts a receiver on the camera or the mixer. Systems in this class are specified under 20 ms, putting 2.4 GHz wireless mic latency below the threshold where most people notice anything.

They manage it by being a closed pair: one manufacturer owns both ends and keeps the receive buffer short. Bluetooth made the opposite bargain, and pays for talking to everything in buffering.

The catch: the last leg is still a cable, since the receiver plugs into the speaker or camera. If you wanted wireless because your speaker sits across the room with no input jack, a 2.4 GHz system does not solve that, and costs more than the speaker did.

When the cable is the right answer

Buy the cable when any of these is true:

• Anyone is singing. A voice arriving a beat behind the backing track is unusable, and the singer feels it worst. See karaoke delay and what can be done about it.
• Anything is played in time. Guitar, hand drums, a metronome, a dance class count.
• People can see the talker's mouth. A hundred milliseconds of lip-sync error reads as a badly dubbed film.
• It is going on video. Fix it in every edit, or fix it once with an eight dollar cable.

The equipment is unglamorous and cheap. A wired dynamic microphone such as a Shure SM58 into a quarter-inch input is the case every wireless option approximates. Some speakers make it easy: the JBL PartyBox series has a microphone jack on the back panel, and the JBL-specific walkthrough covers when to use it and when the phone is less trouble.

When the phone over Bluetooth is good enough

None of that applies to most of what people need a microphone for. Speech with no music under it survives 150 ms without anyone in the room noticing, because there is nothing for it to be out of time with. A teacher reaching the back row, a coach on a touchline, a guide talking to twelve people in a museum: the delay is invisible.

That is the case our app is built for. It routes the phone's microphone into whatever output iOS has already selected, so once a speaker is paired in iOS Settings and holds the live route, your voice comes out of it. The phone is the microphone, not a receiver: it cannot be made to play audio coming from another device. The wider picture is in the measured numbers and the fixes that exist.

You can try the signal chain without installing anything. The browser mic monitor runs the same live pass-through with a gain control, so you can hear your voice through your own speaker and judge the delay before deciding whether a cable is worth buying.

The headset microphone trap

One tempting shortcut makes everything worse: the microphone built into a Bluetooth headset or earbuds. A Bluetooth link holds one profile at a time. The moment something asks for that headset's microphone, the connection drops out of A2DP stereo into HFP, the narrowband mono profile built for calls, and quality falls off a cliff for everyone listening. iOS gives you no control over the switch.

This is why phone-microphone-in, speaker-out sounds better than it has any right to: with the phone's own microphone doing the work rather than a headset's, the link normally stays on A2DP instead of dropping to HFP. Normally, not always. iOS can still put a session into a call-oriented mode in some configurations, and the common exception is a car head unit that is already connected for hands-free, which the phone treats as a call device. If the sound suddenly goes narrowband and thin, that is what happened, and the fix is to pick a different output rather than to look for a setting in the app. The profile switch and what it does to your sound demonstrates the drop in your browser.

What to buy, in order

1. Nothing. If the job is speech to a room and you own an iPhone and a Bluetooth speaker, test what you already have. Plenty of people buy hardware for a problem they never had.
2. A cable. If your speaker has a microphone jack and anyone is going to sing, a dynamic mic and a cable end the conversation for under fifty dollars.
3. A 2.4 GHz system. If you must move around and cannot tolerate delay, this is the answer, at several times the price of the cable.
4. A Bluetooth fix. There isn't one. Every product that promises the delay away is either wired somewhere you did not notice, or is not measuring.

That last point is the one to keep. The gap between wired and Bluetooth is not an implementation problem waiting for a better app. It is structural. What varies between apps is gain, filtering, feedback handling and honesty, and there is more on that across all the guides.