> I've never understood why Wi-Fi latency is only 2-3ms while Bluetooth is 100-200ms when they use the same frequency band.

You're mixing up two different things. Transport latency of WiFi is 2-3ms, but for bluetooth you're suddently talking about a transport, codec, receive buffer and playback code latency. That's not an apple-to-apple comparison.

If you want comparable numbers, measure the latency of audio being streamed from one computer to another via PulseAudio and you'll quickly see that it's more than 2-3ms. And there's a reason for that: most people strongly prefer their music to not stutter and work properly with all kinds of headphones instead of having absolutely no latency. Most people prefer to shove their phone in a separate room, back pocket and walk around RF saturated areas and still listen to music without interruption.

Hence the manufacturers err on the side of buffering some audio so it's more resilient to connection dropouts. You wifi, after all, doesn't need to move around busy highways and public transport systems.

I'd assume a combination of larger buffers for seamless error recovery and also for lower power consumption. The receiving side of that bluetooth connection is also typically extremely battery constrained.

Oh I'd never considered lower power consumption as a reason for increased latency.

I don't immediately see the relationship however -- is there anything you could point me to, to explain the mechanism?

To have minimal latency basically everything needs to stay active constantly. CPU is constantly awake sending or receiving data. Radio is constantly awake. Interconnects constantly awake. If you instead send a large buffer, you can sleep between bursts of work. Dropping to lower power states in the interim, and only a small DSP doing the audio output needs to be awake.

Overhead that’s not linear with the buffer size. The cost (in CPU time, etc.) of updating a 480 sample buffer is similar to that of a 64 sample buffer.