Bluetooth stack modifications to improve audio quality on headphones without AA (2019)

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.

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

It's Bluetooth not having enough latency.

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.

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.

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.

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

Right, it’s more of a configuration that is being changed. But my point was that this is all above the HCI layer, so at the end of the day it’s related to the specific host-stack implementation and not to do with Bluetooth in general.

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

Unrelated: Every once in a while you'd see a familiar name on this website. Thank you for goodbyedpi, it saved me when all isps in my country started blocking raw.githubusercontent.com among others ofc :)

Good work putting all this together. Not saying anything is wrong necessarily, but missing part of the picture.

Not really. Just experience

Nope

Does that definitely negate the value in merging this?

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.

It also predates the Bluetooth headset audio spec update that came out a few weeks ago. Hasn’t reached hardware yet, though.

I use Wireplumber+Pipewire on Ubuntu and Manjaro. I stuffed the following into /etc/wireplumber/bluetooth.lua.d/bluez_monitor.properties :

    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 ]",
    }

Then from the GNOME audio settings I can pick the appropriate codec from the dropdown.

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.

> Or how to check what my current headset is using?

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

If you're on a distro which has migrated to pipewire+wireplumber, the available and active bluetooth profiles can be discovered with something like:

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

And by default, wireplumber will enable all of the codecs it has been built with [https://pipewire.pages.freedesktop.org/wireplumber/configura...].

I use Linux Mint with airpods no problem -- what are you running into? Are you just trying to pair and use as audio sync or also read battery levels?

Well they can advertise how much memory they have...

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

There are inexpensive headphones with the entire MP3 player built in, so I doubt a little RAM would make much difference.

Yeah, memory on these devices tends to be pretty tight. The other challenge with buffering ahead so much is that if you do skip, you’ve basically used your energy budget for 0 value. You’d have to make the argument that there’s net savings, but that would only materialize with predictions that are right enough that the savings outweigh the times you lose (e.g. a simplest heuristic would be if the audio stream has been live for 5 seconds without skipping, send the available buffer at faster than realtime).

Well the protocol would need support for "something happened, drop the buffer".

PulseAudio calls it "rewinding" for example:

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

You could use BLE to signal the incoming call or switching tracks or queuing up a new track. Likewise I’d love it if re-encoding the AAC from the player weren’t a necessary step when there isn’t additional audio. But then I suppose they would have to mix the audio on headphones which … actually sounds doable given that’s basically what noise cancelling and transparency mode requires already.

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.

I can't hear any difference. I think the sample music provided might not be the best - it's too electronic and processed already, my brain doesn't know what it's supposed to sound like.

Thank you, also found this -https://gist.github.com/dvf/3771e58085568559c429d05ccc339219