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

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.

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.

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.

I think Bluetooth 5.0 includes something where the audio latency is communicated back to the phone.

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.

So at least with a browser on Windows it's not done.

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

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.

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.

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

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

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.

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.

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

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

And what the writer is not acknowledging at all is that the underlying hardware being used is highly variable. Android runs on top of numerous Bluetooth chipsets. So when he gets a patch to seem to work on his hardware, there is no saying that it will work for a different Android phone.

Furthermore, this all depends on what else the device is up to at the current moment. If you have shared BT+Wifi chipset and you are streaming a video over wifi, then streaming the audio to your headphones, the device is having to allocate resources based on wifi usage and BT. So playing audio stored locally and audio via a stream is not necessarily going to get the same CODEC parameters.

There is so much nuance to this subject that the author just hasn't considered. Please be careful what you read.

It’s not a bug that the patchset is doing, but enables dual-channel SBC to be negotiated in the source and sink connection. This enables the higher bit-rate without exceeding the maximum bitpool both Android and BT receiver impose.

There’s still negotiation occurs between the source and sink and if either one of them doesn’t support dual-channel SBc, it’ll fallback to whatever its supported. All the device that i had maintained supports it, while some cheap speaker that i test at that time doesn’t and able to negotiate joint stereo session.

I guess I’m basically saying the title should be changed

Here you are https://habr.com/en/articles/456182/

I have seen the bluetooth range drop off in higher quality modes, which seems to confirm it's actually changing the codec (or at least something) and not just a placebo.

https://www.bluetoothgoodies.com/a2dp/ (i have no affiliation)

I hope someone over at Google merges this, or something like this, already. Better audio codec are supported by tons of headphones and such, but support is not universal and bidirectional audio improvements definitely aren't.

I'm not up on the distinctions here but it seems like people may have older headphones where this could still result in improved quality and it seems like low hanging fruit.

Or how to check what my current headset is using?

I remember I had previously a patched pulseaudio that exposed appropriate settings, but later it got "merged into mainstream" - and I couldn't find the settings or information what is being used.

    bluez_monitor.properties = {
      ["bluez5.enable-msbc"] = true,
      ["bluez5.enable-sbc-xq"] = true,
      ["bluez5.enable-hw-volume"] = true,
      ["bluez5.headset-roles"] = "[ hsp_hs hsp_ag hfp_hf hfp_ag ]",
      ["bluez5.codecs"] = "[ sbc sbc_xq aac ldac aptx aptx_hd aptx_II aptx_II_duplex faststream faststream_duplex ]",
    }

I have a pair of Oneplus buds (the older ones, with a wire in between them) so I don't get any of the newer codecs, but SBC-XQ works well for reducing latency in a pinch.

Pulseaudio also has support, but I don't know how to make that work. My last attempt led me to switch to Pipewire.

  pw-dump | jq -r '.[] | select(.type == "PipeWire:Interface:Device" and .info.props."device.bus" == "bluetooth") | .info.params.Props, .info.params.PropInfo'

`pactl list` should show you all your input and output sinks and what profiles they are using. Even though, I think the pulseaudio Volume Control app also shows this graphically.

Something like `pactl set-card-profile bluez_card.98_52_3D_7E_5D_DE a2dp-sink-sbc_xq` sets the profile to sbc xq. This is a bit old and I am not sure if newer versions of pipewire have better ways of doing it.

Ie. if I'm playing a 1 minute song, the whole song should get buffered up. Obviously, if I click 'pause' or change the volume, the buffer should be discarded.

But the long buffer should let my phone sleep more of the time (saving power), and survive poor radio connectivity.

From my foray into audio app (quite a while ago, I admit), I imagine application support would be tricky as well.

RAM uses less power than keeping a radio alive, so I suspect aggressive buffering is a net energy saver.

PulseAudio calls it "rewinding" for example:

https://www.freedesktop.org/wiki/Software/PulseAudio/Documen...

Of course, the cynic in me wonders why we can’t do AirPlay 2-style functionality with simple Bluetooth and BLE speakers, but Apple wants to preserve their margin and ecosystem. Literally lossless headphone audio was mostly a thing with cords, and we’re still playing catchup to the idea.

I do remember a brief period a period in the late 00’s when “MP3 headphones” were a thing, and you could add an SD card to your headphones and listen wirelessly. I’m not sure any of those supported FLAC though.

My suspicion is that in the future, we will skip Bluetooth and go straight to wifi and cellular, where these tiny AirPods end up connecting to audio sources directly and basically only use BLE to sync between themselves. That way you can “leave the phone at home,” etc. They would probably have built-in storage too, for offline support.

Very sad. Android is open source code with an closed development model. Most communication and design work happens behind closed doors, cutting off anyone who doesn't work at Google.

The UX needs some work, but the feature is fantastic.

_magic_ *-*

Random audio glitches are even more annoying than poor frequency response and robotic-sounding music to me...

I think the answer is yes.

Is the Android Bluetooth stack usable on Linux in general? It seems to work a whole lot better and with more devices, so would be great if it was usable.