There are low latency bluetooth protocols, if you sort by latency on rtings for aptx-LL you can see some headsets are down below 40ms. Of course, this relies on both the host and the headset having support for the protocol and being engineered well. SBC and aptX just aren't designed for low latency, and low latency is something that can't be hacked into every codec after the fact.

I'll argue that an device meant for phone calls (which is where bluetooth audio started out!) should aim for low latency by default. I also understand that the CPU/Latency/Memory trade offs made over a decade ago are not the same one's we'd make now.

Doesn't change the fact that the same device can have a 3x latency difference between platforms with the same codec.

Google went and developed VP9 as a royalty free codec in the AV space, they should do something similar for Bluetooth. Right now if I'm on a video call with someone and we both have BT headsets, it is very possible that there is a 500ms audio latency!

Latency on calls over cellular networks is already very high (my subjective experience). But we humans are good at working around it when it's just two people - wait for the other person to finish speaking before you speak, and the other person might have a little longer delay before hearing your response.

If there are multiple parties on the call, this breaks down, because if two people want to speak, they both start talking and don't realize it for a little while.

On video calls this also breaks down, because either video and audio get out of sync (like with zoom) or you get odd artifacts in either the video or audio as they are kept in sync.

> I'll argue that an device meant for phone calls (which is where bluetooth audio started out!) should aim for low latency by default. I also understand that the CPU/Latency/Memory trade offs made over a decade ago are not the same one's we'd make now.

It turns out that the device that's meant for phone calls has to, first and foremost, make sure that there are no dropouts, crackles and other buffer underrun articles. Latency comes afterwards.

What about LC3? It was announced a year ago?

apt-x is designed for ransom extraction via "intellectual property" licensing.

How is this different from any other licensing?

I would be happy if something could be done to prevent audio latency for all devices on my system from permanently increasing if I ever connect a bluetooth audio device.

On Linux, I have to restart pulseaudio after using Bluetooth audio, otherwise retroarch is unplayable.

BTW where are you getting numbers for 200ms latency being average on desktop? My understanding was that latency is typically around 40-50ms on desktop if you are using analog speakers.

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

Is it intentional to ensure there's plenty of buffer so audio packets can be re-sent when they fail, and the audio is seamless? In other words, is 100-200ms just inherent at that frequency with expected interference?

Or is it actually just terribly designed?

> 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.

There is AptX LL (low latency). I have no idea how widespread support is, but you can buy BT dongles, eg to connect video equipment.