Do you know how bluetooth is handling play/pause buttons while listening?
By using a different protocol named AVCTP, while the stream uses AVDTP (with A2DP on top).
A nice way to fix this issue would be to have a kind of bluetooth bonding: 1 connection for receiving audio/video, and the other for sending audio from the mic. That would use up to twice the bandwidth, so fewer bluetooth devices could be around maybe, but it would be nicer.
The real issue, I think, is mostly the fact that supported codecs are all in firmware of the chips used in the headset and laptop, and cannot be upgraded.
Otherwise we could have used Opus for voice codec a long time ago.
I didn't know about the AVCTP, but I completely agree on the possible alternatives Bluetooth could use.
From what I've read in the last few days researching to write the post, it feels like Bluetooth was designed under some constraints 20 years ago, and it keeps using the same constraints.
For example, it's unreal to me that the bandwidth for a Bluetooth connection is around 3 Mbps when we've had 4G with 100 Mbps for over 10 years, let alone 5G at 20Gbps.
And yes, the codecs in the firmware is really bad, although very convenient for the companies selling devices I guess. There aren't enough incentives there for the change.
A2DP would not be a good choice for real-time audio, since it's optimized for quality and defined latency rather than low latency. It does so by using reliable transports which use large retransmission buffers, making latency much worse.
An analogy would be Shoutcast (MP3 audio streaming, mostly used for web radio) vs. RTP (mostly used for real-time communications these days): Both have their strength and weaknesses.
Comments
Do you know how bluetooth is handling play/pause buttons while listening?
By using a different protocol named AVCTP, while the stream uses AVDTP (with A2DP on top).
A nice way to fix this issue would be to have a kind of bluetooth bonding: 1 connection for receiving audio/video, and the other for sending audio from the mic. That would use up to twice the bandwidth, so fewer bluetooth devices could be around maybe, but it would be nicer.
The real issue, I think, is mostly the fact that supported codecs are all in firmware of the chips used in the headset and laptop, and cannot be upgraded. Otherwise we could have used Opus for voice codec a long time ago.
I didn't know about the AVCTP, but I completely agree on the possible alternatives Bluetooth could use.
From what I've read in the last few days researching to write the post, it feels like Bluetooth was designed under some constraints 20 years ago, and it keeps using the same constraints.
For example, it's unreal to me that the bandwidth for a Bluetooth connection is around 3 Mbps when we've had 4G with 100 Mbps for over 10 years, let alone 5G at 20Gbps.
And yes, the codecs in the firmware is really bad, although very convenient for the companies selling devices I guess. There aren't enough incentives there for the change.
That bluetooth constraint is probably due to battery usage.
Yep that's another one that has improved significantly over the years.
I charge my headphones once per month, maybe twice. I'd gladly charge them once per week if that means I get nice audio in and outside calls.
A2DP would not be a good choice for real-time audio, since it's optimized for quality and defined latency rather than low latency. It does so by using reliable transports which use large retransmission buffers, making latency much worse.
An analogy would be Shoutcast (MP3 audio streaming, mostly used for web radio) vs. RTP (mostly used for real-time communications these days): Both have their strength and weaknesses.