It’s 2025(!), and I thought I’d kick off the year with a post about some of the work we’ve been doing behind the scenes for a while. Get a cup of
$beverage_of_choiceand let’s jump in with some context.
History: Hearing aids and Bluetooth
Various estimates put the number of people with some form of hearing loss at 5% of the population. Hearing aids and cochlear implants are often used to help deal with this (I’ll use “hearing aid” or “HA” in this post, but the same ideas apply to both). Historically, these were standalone devices, with some primitive means of receiving audio at a distance (hearing loops and telecoils).
As you might expect, the past two decades have seen advances that allow consumer devices (such as phones, tablets, laptops, and TVs) to connect directly to hearing aids via Bluetooth. This can provide a significant quality of life improvement — playing audio from the device’s speakers means that the sound is first distorted by the speakers, and then by the air between the speaker and the hearing aid. Avoiding those two steps can make a big difference in the quality of sound that reaches the user.
Unfortunately, the previous Bluetooth audio standards (BR/EDR and A2DP — used by most Bluetooth audio devices you’ll find) aren’t ideal for these use cases, especially from a power-consumption perspective. This means that HA users must rely on devices using proprietary protocols (usually limited to Apple devices), or have a cumbersome additional dongle with its own battery and charging requirements. – charge.
Recent Past: Bluetooth LE
The newer Bluetooth LE specification addresses some of the issues with the previous spec (now known as Bluetooth Classic). It provides a low-power base for devices to communicate with each other, and is widely adopted in consumer devices.
On top of this, we have the LE Audio standard, which provides audio streaming services over Bluetooth LE for consumer audio devices and HAs. The hearing aid industry has been an active participant in its development, and we should see widespread support over time, I expect.
The basic Bluetooth LE specification has been around since 2010, but the LE Audio specification has only been public since 2021/2022. We’re still seeing devices with LE Audio support trickle down the market.
In 2018, Google teamed up with a hearing aid manufacturer to announce the ASHA (Audio Streaming for Hearing Aids) protocol, presumably as a stop-gap. The protocol uses Bluetooth LE (but not LE Audio) to support low-power audio streaming to hearing aids, and is
available to the public. Many devices have been shipped with ASHA support in the last ~6 years.
Hot Take: Simplicity is not good UX
As end-users, we understand the push/pull of technological advancement and obsolescence. As responsible citizens of the world, we also understand its impact on the environment.
The problem is even worse when we talk about medical devices. Hearing aids are expensive, and expected to last a long time. It is common for people to use the same device for 5-10 years, or longer.
In addition to the financial cost, there is also a significant emotional cost to changing devices. There is usually an adjustment period during which one may work with an audiologist to fit one’s hearing device. Neuroplasticity allows the brain to adapt to the device and gain more meaning over time. Changing devices effectively resets the process.
All of this is to say that supporting older devices is a worthy goal in itself, but there is an additional set of dimensions in the context of accessibility.
HAs and Linux-based devices
Because of all this history, hearing aid manufacturers have traditionally focused on mobile devices (ie Android and iOS). This is changing, with Apple supporting the proprietary MFi (made for iPhone/iPad/iPod) protocol in macOS, and Windows adding support for LE Audio in Windows 11.
This leaves the question of Linux-based devices, which is our main concern — can users of free software platforms have an accessible user experience?
A lot of work has been done to add Bluetooth LE support to the Linux kernel and BlueZ, and more to add LE Audio support. PipeWire’s Bluetooth module now includes support for LE Audio, and there is an ongoing effort to develop it. Linux users with LE Audio-based hearing aids can take advantage of all of this.
However, the ASHA specification is only supported on Android devices. This is a bit of a shame, as there are likely to be a significant number of hearing aids out there with ASHA support, which will hopefully be around for the next 5+ years. It feels like a gap that we can help fill.
Step 1: A Proof-of-Concept
We start by looking at the ASHA specification, and the status of Bluetooth LE in the Linux kernel. We see some things exposed in the Android stack that BlueZ doesn’t, but it looks like all the pieces should be there.
friend-of-Asymptotic,
Ravi Chandra Padmala spent some time with us implementing a proof-of-concept. This was an intense journey in itself, as we had to identify some good reference hardware (we found an implementation of ASHA in eleventh RSL10), and clean the pipes between the kernel and userspace (LE connection-oriented channels, which ASHA relied on, were not commonly used at the time).
Finally we got the
proof-of-concept is done, and it gives us the confidence to move to the next step of integrating it with BlueZ — albeit after a break from paid work. We have to keep the lights on, after all!
Step 2: ASHA in BlueZ
The BlueZ audio plugin implements various audio profiles within the BlueZ daemon — these include A2DP for Bluetooth Classic, as well as BAP for LE Audio.
We have decided to add ASHA support within this plugin. This will allow BlueZ to perform privileged operations and then provide a file descriptor for the connection-oriented channel, so that any userspace application (such as PipeWire) can stream audio to the hearing aid.
I implemented an initial version of the ASHA profile in the BlueZ audio plugin last year, and thanks to Luiz Augusto von Dentz’
guide and reviews, the plugin has
landed above the river.
It has been tested with a hearing aid, and stereo support is pending. In the process, we also found a small community of people with a deep interest in this topic, and you can join us #asha on
BlueZ Slack.
Step 3: PipeWire Support
To get end-to-end audio streaming working in any application, we need to expose the BlueZ ASHA profile as a playback device to the audio server (ie, PipeWire). This will make the HAs appear as just an audio output, and we can route any or all audio systems to it.
my partner, Sanchayan Maitybeen working on it for the last few weeks. The code is in place now, and you can track our progress at PipeWire MR.
Step 4 and beyond: Testing, stereo support, …
Once we have basic PipeWire support, we’ll implement stereo support (the spec doesn’t support more than 2 channels), and then have a bunch of testing and feedback available. The goal is to make it a stable and reliable solution for people on Linux-based devices with hearing aids.
Once that is done, there are many UI related tasks that are good to get to in order to provide a good user experience. This includes things like combining the left and right HAs to make them appear as one device, and access to any tuning parameters.
Finish it
This project has been on my mind since the ASHA specification was announced, and it’s been a long road to get here. We are in the attractive position of being paid to work on challenging problems, and we always contribute our work to the flow. However, there are many such projects that can be valuable to society, but do not necessarily have a clear source of funding.
In this case, we find ourselves in an interesting position – we have the expertise and context around the Linux audio stack to get it done. Our business model allows us the luxury of taking bites out of problems like this, and we’re happy to do so.
However, it would be very helpful if we had the funds to continue this work to the end – we could focus on the whole task and get it done faster.
Continue…
I am happy to announce that we found the financial support to complete the PipeWire work! Once we get MR’s basic mono audio support up and running, we’ll move on to implementing stereo support in the BlueZ plugin and the PipeWire module. We’ll also be testing with some real-world devices, and we’ll be relying on our community for more feedback.
This is an exciting development, and I will write more about it in a follow-up post in a few days. Watch out!
(Note: This post was originally published
HERE).
2025-01-08 14:27:00
