Isn't it just the need for low latency? "Media" (music, videos etc) has good sound quality but significant latency. It gets compensated by delaying the video by an equal amount, but it's too much latency for phone calls.
Everyone who wants a standard to require their patent is allergic to it, but Opus was designed for exactly this. It’s acoustically transparent at moderate bit rate, good enough at lower bit rate, and adds minimal latency.
Bluetooth HFP 1.9 includes support for LC3 codec for Super Wideband Speech (SWB) in Handsfree mode [1], with 32kbps bitrate.
Quality is significantly better than SBC. ETSI has tested this extensively and came to the conclusion that LC3 is better than Opus in some common conditions [2]
Quote: LC3 at 32 kbps (LC3 32) provides significantly better audio quality than Opus-CELT at 32 kbps and complexity level 0 (OPUS_v114_c0 and COPUS_v114_c0)
So there IS a solution for higher quality, which is LC3-SWB. It's just that both devices need to support HFP 1.9 to make use of better codecs, which will take a while especially on the headset side.
The SBC bitrates discussed in the article are nuts. Opus is transparent at 1/5-1/4 of those rates. OTOH it’s newer and maybe ten-year-old cheap Bluetooth chips couldn’t have handled it.
Also keep in mind that you would also need realtime transcoding on the transmitter, as the device would need to mix whatever audio-codec is provided with other channels (Notification sounds, etc.) and encode it into Opus on-the-fly.
Not sure what is a failing unique to capitalism here. The USSR had a standards body comparable to western ones (Gosstandard) and that still has plenty of political infighting and abuse. And for all of capitalism's failings, I don't think it's had any scientific failings on the level of Lysenkoism.
Capitalism isn't bad per se, however capitalism without any limitation can be quite dangerous for allowing too much power in the hands of too few entities.
> It gets compensated by delaying the video by an equal amount
Is this actually done? Who would be doing it, the OS? It just sounds like the separation of concerns and the design of the interfaces would make it pretty unlikely.
Yup, Bluetooth devices can report the latency via AVDTP 1.3 Delay Reporting. If I remember correctly from the last time I looked at this, the media framework in OS's tend to expose this to applications by reporting the timestamp that a submitted audio buffer is actually played back. The video player can use these timestamps to adjust the video delay accordingly. And since it's per buffer, it can handle the latency changing (eg. by switching from Bluetooth to a wired connection).
I know at least Android and Linux + Pipewire support this. I haven't encountered a single application on desktop Linux that doesn't support this properly. All the standard video players and browsers work. It works for HDMI too, when the TV/AV receiver is well designed and communicates the latency in the EDID.
Indeed, there is some (usually much smaller, but depending on buffer sizes) audio delay even in regular desktop systems so video players and audio APIs mostly already had proper handling for it.
Empirically: videos are perfectly synced using my Sony headphones (which use Bluetooth 5.0) on Android. But anything interactive (games, and UI sound effects) has a significant delay.
I think Bluetooth 5.0 includes something where the audio latency is communicated back to the phone.
Yeah, playing twitchy games with bluetooth on is janky suicide. I was trying to play a difficult platformer on my phone with a clipped-on game controller and it was miserable until I switched to wired audio.
Not sure if it was the audio latency or the crowded traffic on bluetooth slowing down my BT game controller, but the difference in feel and success was night-and-day when I did that.
Not always. Just got some wireless headphones at work, and now I can no longer enjoy YouTube videos (mostly KEXP) because of the 100ms audio delay. It's too disturbing even only in side view.
So at least with a browser on Windows it's not done.
I’ve definitely noticed it on macOS. Videos in the browser will stall for a fraction of a second after pressing play to give the audio time to catch up.
