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.
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.
Love that profits plunder progress.
No no no, capitalism is supposed to make BETTER products, because money! You must be mistaken.
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.
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.
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.
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...
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.
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.
"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...
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.
It is absolutely done, mostly by the media player/library used, e.g exoplayer on Android has automatic lag compensation for that purpose.
It's Bluetooth not having enough latency.
I meant to say bandwidth.
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.
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.
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).
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.
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.
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.
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.
Please can someone invent a bluetooth audio profile which allows buffering a long time in advance?
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.
Unlikely to happen. I sincerely doubt most headphones would have the memory for that buffer. Sure, it's only a megabyte or two of ram, but your headphones would have to spend valuable battery on keeping that ram active.
From my foray into audio app (quite a while ago, I admit), I imagine application support would be tricky as well.
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.
Reminds me of the old portable CD players that would advertise the capacity of their anti-skip buffers.
Sony Bluetooth headphones, now with 10 seconds g-shock protection!
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).
IIRC, Spotify applies a similar strategy also for deciding which music to already fetch from the servers when listening to a playlist to minimise the gap between pressing next song and actual playback. It seems like it should be exactly the same algorithm for sending it to the headset, with the exception of other sounds like notifications/calls.
There are inexpensive headphones with the entire MP3 player built in, so I doubt a little RAM would make much difference.
You'd love that until the phone rings and you want to pre-empt all that buffered stuff with your incoming call rather than to first listen to the next minute of Led Zeppelin.
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...
Right, true, or some kind of priority queue.
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.
Well that's doable with enough embedded memory, but it will become an issue when you want to sync audio and video. So it really is less of a protocol thing and more of something that an individual product could design in, allowing a user to toggle the feature via an app.
That is pretty much explicitly against what most users want from audio unfortunately.
Perhaps interesting to note: on Linux, you can also enable higher bitrate SBC audio (though something dubbed "SBC XQ"). Similarly, "mSBC" can be used for higher quality headset audio (still nowhere close to SBC or more APTX, of course).
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.
Do you know how to enable that on Linux?
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.
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.
Not sure about Gnome, but in KDE you can select the codec from a drop-down in volume panel for a while now. I got high quality headset audio with low delay for at least 2 releases of Fedora.
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 ]",
}
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.
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'
This is a 4 year old article that predates things like LE Audio support for which has been merged into Android.
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’m struggling so hard just to even barely support Airpods in Linux :’)
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?
Just pairing them seems impossible. Is there any guide that you found helpful?
This article is not about Bluetooth in general, it is a deep dive into the bugs buried within the Android Bluetooth stack.
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.
This article is not about Bluetooth in general
Here you are https://habr.com/en/articles/456182/
Good work putting all this together. Not saying anything is wrong necessarily, but missing part of the picture.
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 :)
Former custom ROM developer here who has reviewed and integrated valdikSS modification.
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.
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
I’m so glad Bluetooth SIG charges $10,000 per model of Bluetooth device sold just to prevent any interoperability issues!
Do you have any links?
Nope
Didn't think about this, do you have more information about this?
Not really. Just experience
I'm a little skeptical that Dual Channel at 551 kbps results in noticeably better quality than Joint Stereo at 328 kbps as opposed to just using more bits encoding redundant information. At least for most music - eg stuff that isn't intentionally playing around with different recorded tracks on left and right.
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.
Do anyone know whether the new LE Audio standard include high quality duplex audio (headphones + microphone)? Or is it still mSBC 16 kHz?
I actually dug through a lot of the spec to find this out - damn you, Bluetooth SIG.
I think the answer is yes.
Not entirely sure what configuration you're looking for, but the one supported in Android can be found here https://android.googlesource.com/platform/packages/modules/B... https://android.googlesource.com/platform/packages/modules/B...
"Alternative A2DP Driver" offers this functionality on Windows. Lets you customize SBC parameters, use AAC, aptX (apparently, haven't tried). Works well in my experience, lets me use LDAC with my sony XM4's. It's trialware, but cheap.
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)
What is this "Quality Loss" they speak of regarding downsampling from 48KHz to 44.1KHz? When resampling is done properly, you'd only lose very high frequency content (frequencies above 22050Hz). Human hearing range is usually documented as up to 20KHz, but some young people can slightly hear higher frequencies.
I wish something like this existed on MacOs :/
I think it does, https://github.com/ololx/sbc-bitpool-expander
Wasn't expecting a harb link getting to the front of hn. Congrats to the author
Pretty common for habr.com :) https://news.ycombinator.com/from?site=habr.com
What a week written article
Jumping on with a related question: Does anyone know of any way to improve the HFP on MacOS with Bluetooth? The same headset I'm using on Linux with mSBC and pretty good quality - on MacOS it completely sucks and switches to phone line / mono quality. Is there already any hack for Darwin to make it behave properly?
Would be good to add (2019) to the title. It makes statements about "all current Bluetooth stacks", while these things have been implemented in at least PulseAudio and PipeWire for a while now.
i didn't know i was using SBC (Lineage 18-1 doesn't show that UI checkbox when connecting devices with SBC capability) until this post!
_magic_ *-*
Is it possible to measure the signal strength and auto-fallback to lower bitrates as the device starts to go near the edge of range?
Random audio glitches are even more annoying than poor frequency response and robotic-sounding music to me...
This is exactly my vibe. Super cool, props to the author for improving things purely through software.
This is about Android's Bluetooth stack.
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.
This artificial limitation sounds very much like a purposeful limitation to gather licensing fees.
I tried to contact many Bluetooth stack developers from Google, asking them to consider including my patches to the main Android branch—AOSP, but did not receive a single answer.
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.
I have used this in LineageOS and honestly loved the feature. The ability to send higher quality audio to stuff like my car stereo where I don't have any support for 3P codecs. Also headphones can really benefit from this.
The UX needs some work, but the feature is fantastic.
(2019)
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.