Hacker News Reader

Comment by noodlesUK | Hacker News Reader

This is great: SBC is widely supported and this seems like a natural extension of the existing standard. The issue I personally have is not about SBC vs LDAC or AAC, but that HFP is garbage. The moment the mic gets switched on, I’m transported back to the 90s. If someone wants to make bidirectional Bluetooth audio that doesn’t suck, I’d be thrilled.

View on HN

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.

It's Bluetooth not having enough latency.

I meant to say bandwidth.

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

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.

It is absolutely done, mostly by the media player/library used, e.g exoplayer on Android has automatic lag compensation for that purpose.

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.

Yes, this is called AVDTP 1.3 Delay Reporting feature. It allows headphones to report the delay to a sending device that actually plays the sound.

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.

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.

"Using an AirPlay-enabled device for your audio content can result in a 2-second delay. Check for this delay in game content."

https://developer.apple.com/documentation/avfaudio/avaudiose...

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.

Love that profits plunder progress.

It’s true.

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.

What would the power requirements for decoding Opus with a low latency be? Wireless earphones have tiny batteries.

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.

No no no, capitalism is supposed to make BETTER products, because money! You must be mistaken.

Better than what?

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.

Compared to what?

Capitalism with limitations.

How does the patent system follow from capitalism?

It lets people effectively own ideas, prevent others from using them, and potentially license the ideas out for money.

Free-market capitalism is based on competition and low barriers of entry. A government-granted monopoly such as patents is antithetical to capitalism.

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.

[1] https://www.bluetooth.com/specifications/specs/hands-free-pr...

[2] https://www.etsi.org/deliver/etsi_tr/103500_103599/103590/01...

I really don't understand why HFP is still the industry standard. Even devices within the same ecosystem, like MacBook / iPhone / AirPods seems to use it based on the audio quality. Or maybe it's AVRCP. Sounds horrible either way.

There are simply no common successors to HFP. There are a few handsets that use two A2DP streams, but that requires a lot of bandwidth and I don't think support is anywhere close to universal.

Bluetooth 5.2 adds BLE Audio which offers more flexibility. The LC3 codec is supported by Windows 11, Android 13, and Linux, and it significantly improves audio quality compared to the older codecs. I'm not so sure about hardware support in headphones, though.

AVRCP is the control protocol for BT media (e.g. when you volume up or play/pause from your headset). I’m assuming you meant A2DP which is the protocol for receiving audio. HFP is totally separate from A2DP in that it’s a bidirectional audio stream. That bidirectionality is the difficult part - you have in theory tight time bounds for transmitting the data for latency reasons + these cheapo headsets have 1 radio which means they’re nominally limited to tx or rx. Since the assumption for the design is voice calls, you severely clip the microphone audio into the frequency band for speech & transmit mono which is why the audio quality is so bad (+ you further lossy encode it but the frequency reduction is probably the biggest dip). All of this has to fit on top of the PHY packet transport that time-divides access to the channel + has to coex with other 2.4 GHZ radios like WiFi (at least historically).

Now, could these designs be revisited? Probably. Maybe radios are small and cheap enough that we should have 2 and a protocol for bidirectional audio that allows independent streams over separate bands with software synchronizing and mixing audio. It’s also possible the audio encoders/decoders could be modernized with more modern compression techniques to improve audio quality without requiring changes to the bandwidth allocation. Bluetooth those is very ossified and the standards bodies move like molasses - most of the investment is in WiFi and radio vendors are more interested in milking what exists now (or coming up with proprietary solutions like aptx) than actually solving the problems.

BLE Audio supports bidirectional audio up to ±1300kbps ("2Mbps" but with overhead subtracted) which is a LOT better than HFP, especially with LC3 as a replacement for the older codecs.

I don't think many devices support it yet, but the spec has a perfectly acceptable bitrate for modern audio calls. We just need to wait for hardware vendors to pick up on BT5.1 features. Last I read about these I think the focus for BLE audio was on hearing aids and such, but there's no reason the spec couldn't be used for headphones.

BLE audio also allows for things like connecting your headphones to multiple sources and broadcasting audio to multiple receivers. The standard has improved significantly, but without cheap, mass produced chips, these advancements will probably be stuck in expensive purpose-built devices for a while.

Yeah I was just reading that the latest standards have improved things so we’ll have to wait a few years for HW to filter out.

> That bidirectionality is the difficult part

Best hack I've come up with when I have to use Bluetooth headsets on calls is to use them unidirectionally by selecting my MacBook microphone as input (try option click on volume control in menu bar).

(... but mostly I go wired most of the time).

Yep, this is also what u do. On top of that, the MacBook mics are way better than any earbud mic.

Just get a wireless headset that uses a USB dongle. It's archaic but it works. I can't stand to be tethered to my desk when I talk. It's annoying and silly how I have a BT headset and a USB-wireless headset on my desk at the same time and I switch depending on whether the call is coming over the phone or the PC, and theoretically I could get one device that does both with a switch (eg. my wife has a Logitech one that does that) but this approach works for me.

I've literally gotten a compliment or two on how great the audio is when I'm doing remote presentations, but maybe that's because I often privately grouse about people who are using awful mic setups and so somebody was watching for that. I'm not using anything fancy, I just buy upper-mid-range gaming headsets (the $150US-ish ones that are good-enough that they don't cover them in neon plastic and LED lighting).

So I assume Sony and Xbox are using Wi-Fi to use Audio on their controllers?

At least for Xbox controllers and headsets (and logitech lightspeed mouses too) they don't use bluetooth, they use a proprietary protocol, you can connect them using bluetooth but if you really want low latency you will need a proprietary dongle.

I suppose sony do something similar, and as far as I know they all use the 2.4GHz band.

Good thing both Xbox and Playstation controllers have a 3.5mm jack and I don't need to buy their overpriced shitty headsets to play without significant audio latency.

Newer HFP headphones at least have mSBC, which sounds slightly less horrible.

Still, I’m also surprised that AirPods don’t use anything better within the Apple ecosystem, proprietary or otherwise.

It's slowly entering the market as LE Audio / Auracast. Might be a while till good os support is available though

While Windows technically supports LE Audio and the profiles required, the encoding and such are left up to the vendor driver to implement.[0]

I'm not even sure if Intel's newer products will actually properly do BAP etc. on Windows because of driver support, despite them listing very windows looking software version numbers in the certification on the Bluetooth SIG site. (AX210 and newer should be capable and advertise proper isochronous channel support in their drivers. AX200 and AX201 are not capable, and but kinda sorta advertise isochronous channel support anyway because of a bug I believe. BE200 obviously capable but they have a separate driver on Windows and I have no idea how stable it is in Linux.)

[0] https://learn.microsoft.com/en-us/windows-hardware/drivers/b...

I can vote for that as well.

Reply on news.ycombinator.com