GN Hearing and Google announce Android streaming partnership


GN Hearing and Google Announce Partnership to Bring Direct Mobile Streaming from Android Devices to Hearing Aids

August 16, 2018 09:00 AM Eastern Daylight Time

BALLERUP, Denmark–(BUSINESS WIRE)–GN Hearing and Google have today announced a new technology partnership that will make GN Hearing the first manufacturer to enable a full spectrum of direct audio streaming from Android devices to hearing aids. The expectations are that direct streaming will become available to hearing aid users of the recently launched hearing aids ReSound LiNX Quattro™ and Beltone Amaze™ in a future Android release.

“According to the World Health Organization, around 466 million people worldwide have disabling hearing loss. This number is expected to increase to 900 million people by the year 2050. Google is working with GN Hearing to create a new open specification for hearing aid streaming support on future versions of Android devices,” states Seang Chau, Vice President of Engineering at Google.

Users will be able to connect and monitor their hearing aids, so they can get the full advantages of their Android devices without using an intermediate device for streaming to their hearing aids. This will allow more people to call friends; and enjoy music and brilliant sound experiences.

“We are honoured to partner with Google for this important development, which will enable direct streaming for even more hearing aid users through their Android devices. This is another example of how GN Hearing relentlessly strives to drive innovation forward by developing new products and solutions with unique benefits for hearing aid users and audiologists around the world”, says Anders Hedegaard, CEO, GN Hearing.

Google has published the new hearing aid specification for Android smartphones: Audio Streaming for Hearing Aids (ASHA) on Bluetooth Low Energy Connection-Oriented Channels. The first hearing aid manufacturer to be able to utilise the new specification is GN Hearing, and in time other hearing aid manufacturers can build native hearing aid support for Android.

About GN

GN is a global leader in intelligent audio solutions, superior sound quality and connectivity. Founded in 1869, GN is dedicated to making life sound better and developing meaningful solutions that transform lives through the power of sound. GN was among the first companies to develop digital hearing aids and, more recently, cloud-based remote fine-tuning, which enables adjustments of hearing aids across continents and time zones. GN is the only company in the world with innovative and intelligent medical and consumer audio solutions, which are marketed by the ReSound, Interton, Beltone, Jabra and BlueParrott brands in 100 countries. GN employs more than 5,500 people worldwide and is listed on Nasdaq Copenhagen.


At last. The announcements start to happen.
I wonder if GN has any exclusivity or if Google is truly making it open.
I also wonder if they’re going to be truly hands free similar-ish to the Phonak.


In first read through, it looks like BT 5 might be involved, but also says 4.2 is minimum. Will need to read more.


Anybody read the link that has the background to understand it? It references Bluetooth Core Specification Version 5, but I don’t think that’s the same as Bluetooth 5. It sounds like this will work with Bluettoth 4.2. Anybody really get what this is saying?


It may be how much the particular chip can support. It could be the need for a new driver but most older phones won’t ever see that upgrade. Different phone may have one chip or another.


it has less chance since signia nx series require streamline mic android 4.2 or higher and never advertised for upcomming android direct streaming so 5.0 is highly likely


Kinda, Sorta. Maybe…

Still sorting through Google searches on unfamiliar terms and acronyms, getting all the puzzle pieces right side up, then I’ll try to assemble them. :wink:

These all seems to be present in the BT protocols, but how those protocols are used is different. I’m not getting it clear in my mind what the GATT server in the peripherals is, hardware of software. This seems to be the key to getting this to work and what is appartently in the new GN Quattro.

I understand this so far.
Central is phone, Peripherals are HAs
COC - Connection-Oriented L2CAP Channels over Bluetooth Low Energy
L2CAP channels - Logical Link Control and Adaptation Layer Protocol

Here are GATT services part ot BT 5 specs so it seems to be firmware not hardware (chips). GATT means Generic Attributes.

Here are BT Core specs

Pieces are clicking now. :+1:


A few takeaways I got from the “quotes” below;

  1. The Bluetooth audio system views the left and right peripherals as a single audio sink. If a peripheral is missing, due to a monaural fit or a loss of connection, then the central mixes the left and right audio channel and transmits the audio to the remaining peripheral.” That means that the protocol provides full stereo headset to both hearing aids while it can do so, and if not it will revert to sending the combined signal to one hearing aid.
  2. Note: There is no audio backlink between the central and the peripherals. During a phone call the central microphones (meaning the cellphone microphone) are used for voice input.”. This means that using one of the hearing aid microphones to speak as in the (Phonak B Direct, Unitron Moxi ALL, Phonak Brio 3 R-C) models will not be supported. I suspect we have seen the last of using a hearing aid microphone to speak on a phone call.
  3. Hearing aid devices (HA) can have improved accessibility on Android-powered mobile devices by using connection-oriented L2CAP channels (COC) over Bluetooth Low Energy (BLE). COC uses an elastic buffer of several audio packets to maintain a steady flow of audio, even in the presence of packet loss. This buffer provides audio quality for hearing aid devices at the expense of latency.” This means the voice signal will likely be robust because of this elastic buffer. But if signal interference is too bad you will begin to suffer long latency.


As an aside: I saw a thread on this forum referenced by this article: Google is bringing native hearing aid support to Android | VentureBeat.


Well…poop. I quite like the idea of truly hands free. I guess we’ll see how long Phonak keeps that going. Maybe they’ll strike their own path.


I’ve been trawling through the various tech news sites. Some are saying low-latency, others are saying high quality audio at the expense of latency. It’s a pretty important difference. Obviously a comprehension problem on my part, so can someone help me out?


I was hoping for an official Bluetooth SIG standard. This doesn’t appear to be it.


“expense of latency” First paragraph of this tech doc:

Hearing Aid Audio Support Using Bluetooth LE

Hearing aid devices (HA) can have improved accessibility on Android-powered mobile devices by using connection-oriented L2CAP channels (COC) over Bluetooth Low Energy (BLE). COC uses an elastic buffer of several audio packets to maintain a steady flow of audio, even in the presence of packet loss. This buffer provides audio quality for hearing aid devices at the expense of latency.

next paragraph ->

The design of COC references the Bluetooth Core Specification Version 5 (BT). To stay aligned with the core specifications, all multi-byte values on this page should be read as little-endian.

Click that “Bluetooth Coore Specifications Version 5” link and it takes you to the Bluetooth specs page and mentions the Bluetooth SIG Working Group. That page appears to be the work of the SIG, and it appears to me that it is using the official BT SIG standard.

I’ve been going through that page most of the day, using Google searches trying to understand it as thoroughly as I can. Like you, that “high quality audio at the expense of latency” is not clear to me what that means in terms of streaming voice or audio.


I’m thinking it means that if you have good/interference-free communications between your cellphone and your hearing aids then you will have high-quality-audio and low-latency and everything will be peachy.

But if you have too much interference, or if the hearing aid processor is too busy then the elastic buffer can provide some extra slack to attempt to maintain the state of high-quality-audio and low-latency. If communications problems persist to the extent the elastic buffer is full, then latency has to suffer in order to not drop the connection completely.


That makes sense, I see that now as well. It helps when someone else points something out with their thoughts, thanks.

That would be part of the reason for the increased processing power of the Quattro in the announcement of 100% more speed and 100% more memory.


That’s some pretty good reasoning @pvc and @teejayess.

I’m not sure of what’s really happened here. Has Google done an Apple and created their own standard? At least it’s ‘open’ I guess, so others can play. So here’s Google, who are one of the handful of organisations at the top level of the Bluetooth Special Interest Group. The Bluetooth SIG has a Hearing Aid Working Group who are supposed to be working hard to come up with an official hearing aid profile. Google seems to have bypassed that entirely and done a deal with one hearing aid manufacturer. Where does that leave the Hearing Aid Working Group? Are we going to have two competing non-official standards? Do hearing aid companies need to take sides?


DejaVu, the Betamax/VCR wars? Who knows? :stuck_out_tongue:

Maybe the hearing aid Firmware could support both communications protocols (Android and MFi or newer MFi). However if one protocol has superior performance over the other, then that’s bad news for the other.

Oh, I don’t think it’s just one manufacturer. GN is likely just the first in announcing it.


I’m sure you’re right but they did all the development with GN. Maybe they just got sick of nothing happening through the working party and decided to use their muscle.


This is an open Bluetooth compliant protocol. It can be used by any HA manufacturer or Android phone manufacturer.

Bluetooth has it’s own radio to manage the Bluetooth stack. This partnership was just the initial collaboration to get it started, but it is not a closed source like Apple MFI.

Here is more in a more layman frriendly explanation:

This cleared most of the mud for me:

ASHA is designed to have a minimal impact on battery life with low-latency while maintaining a high quality audio experience for users who rely on hearing aids. We look forward to continually evolving the spec to even better meet the needs of our users.

The spec details the pairing and connectivity, network topology, system architecture, and system requirements for implementing hearing aids using low energy connection-oriented channels. Any hearing aid manufacturer can now build native hearing aid support for Android.

There are still many unanswered questions,that will get answered in the next few months.


Here is another write up that helps to explain more clearly.