[HN Gopher] Bluetooth stack modifications to improve audio quali...
___________________________________________________________________
Bluetooth stack modifications to improve audio quality on
headphones without AA
Author : todsacerdoti
Score : 154 points
Date : 2023-11-23 19:41 UTC (3 hours ago)
(HTM) web link (habr.com)
(TXT) w3m dump (habr.com)
| noodlesUK wrote:
| 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.
| baxuz wrote:
| 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.
| jeroenhd wrote:
| 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.
| davidhyde wrote:
| LC3 (Low Complexity Communications Codec) has low
| computational complexity so low power headphones should be
| more than capable of decoding it. I'm not aware of
| headphone support either though. Who knows how long it will
| take until we see them. That codec was released in
| September 2020, smack bang in the middle of the chip
| shortage.
| vlovich123 wrote:
| 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.
| jeroenhd wrote:
| 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.
| vlovich123 wrote:
| 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.
| lloeki wrote:
| > 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 the MacBook microphone as input.
|
| (but mostly I go wired most of the time).
| HPsquared wrote:
| 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.
| eptcyka wrote:
| It's Bluetooth not having enough latency.
| therein wrote:
| > 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.
| magicalhippo wrote:
| 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.
| explodingcamera wrote:
| It is absolutely done, mostly by the media player/library
| used, e.g exoplayer on Android has automatic lag
| compensation for that purpose.
| amluto wrote:
| 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.
| photoGrant wrote:
| Love that profits plunder progress.
| zwirbl wrote:
| It's slowly entering the market as LE Audio / Auracast. Might
| be a while till good os support is available though
| btreecat wrote:
| 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.
| luqtas wrote:
| 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_ *-*
| gchokov wrote:
| I wish something like this existed on MacOs :/
| krackers wrote:
| I think it does, https://github.com/ololx/sbc-bitpool-expander
| jeroenhd wrote:
| 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.
| krzyk wrote:
| 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.
| abdullahkhalids wrote:
| > 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.
| viraptor wrote:
| 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.
| jeroenhd wrote:
| 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.
| Lucasoato wrote:
| I'm struggling so hard just to even barely support Airpods in
| Linux :')
| mb7733 wrote:
| 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?
| izacus wrote:
| This is a 4 year old article that predates things like LE Audio
| support for which has been merged into Android.
| velox wrote:
| "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)
| Moldoteck wrote:
| Wasn't expecting a harb link getting to the front of hn. Congrats
| to the author
| londons_explore wrote:
| 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...
| londons_explore wrote:
| 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.
| solraph wrote:
| 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.
| vlovich123 wrote:
| 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).
| spockz wrote:
| 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.
| londons_explore wrote:
| 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.
| jacquesm wrote:
| 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.
| londons_explore wrote:
| 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.
| ..
| jacquesm wrote:
| Right, true, or some kind of priority queue.
| lstamour wrote:
| 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.
| jwtorres wrote:
| 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.
| izacus wrote:
| That is pretty much explicitly against what most users want
| from audio unfortunately.
| JeremyNT wrote:
| (2019)
| jwtorres wrote:
| 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.
| emilfihlman wrote:
| This artificial limitation sounds very much like a purposeful
| limitation to gather licensing fees.
___________________________________________________________________
(page generated 2023-11-23 23:00 UTC)