Google has introduced new protocols and its support for hearing aid manufacturers, using Android and Bluetooth low energy (BLE). With the new standards, the Audio Streaming for Hearing Aid (ASHA) GATT server service, it should help in designing hearing aids devices like Bluetooth headphones. It allows people with hearing limitations, to make phone calls or listen to music over their compatible hearing aid more easily. Moreover, it will show a notification on Android devices with their manufacturer-assigned name, which makes it easier to recognize the Bluetooth hearing device which needs to be connected.

The main differences between a standard Bluetooth device and a hearing aid in Android are in the specification requirements. Hearing aids do not operate BLE long-range PHY and the connection to the device should not be severed when audio stops streaming. In Android, Bluetooth audio devices disconnect from a handset after streaming has stopped for some time. Hearing aids for mobile allow users to hear their smartphone, AOSP guidelines indicate it shouldn’t disconnect from the device.

Hearing aid devices are improved for Android devices by using connection-oriented L2CAP channels (CoC) over Bluetooth Low Energy (BLE). It uses a buffer of audio packets to maintain a steady flow of audio, even during packet loss. This buffer provides audio quality at the trade-off for latency. Hearing aids devices transmit audio through a single central and two peripherals, one left and one right. The Bluetooth audio system sees the peripherals as a single audio sink. If one of the peripherals is missing, then the central mixes the left and right audio channel and transmits the audio to the remaining peripheral. If central loses both peripherals, then it considers the link to the audio sink lost. In this case, the central routes audio to another output.

 There are no audio back links between the central and the peripherals so, during a phone call, the central (mobile) microphones are used for voice input. When the central is not transmitting audio to the peripheral, it can maintain a BLE connection. BLE connection allows the data communication to the GATT server present on the peripheral device.

ASHA GATT services

GATT stands for the Generic Attribute Profile; it defines the way that two BLE devices transfer data using Services and Characteristics. It uses Attribute Protocol (ATT), which stores Services and Characteristics in a lookup table. GATT service begins after a connection is established between two devices and it has gone through the advertising process of GAP. The GATT connections are exclusive which means that a BLE peripheral can only be connected to one central device at a time. As a peripheral connects to a central device, it stops advertising and other devices are unable to see it or connect to it until the existing connection is lost.

Hearing aid implements the Audio Streaming for Hearing Aid (ASHA) GATT service. The peripherals advertise to let the central recognize. The peripheral device must have a Complete Local Name which is used on the mobile device’s user interface so the user can select the right hearing aid device. During the initial pairing, the peripheral advertises at a faster rate to let the central device quickly discover the peripherals and establish a connection.

Synchronizing Peripheral devices

Peripheral devices should be synchronized in order to give the best user experience. Both peripherals left and right must play audio samples from the source at the same time. If the audio is not synchronized it may cause uneasiness and users have difficulty in understanding the audio.

Peripherals can synchronize by using a sequence number prior to each packet of the audio payload. The central ensures that audio packets are to be played at the same time on each peripheral have the same sequence number. The sequence number is 8-bit long and increments by one after each audio packet are played. Each audio packet size and sample rate are fixed for a connection, so the two peripherals can deduce the relative playing time.

The central assists in synchronization by providing triggers to the peripherals when it is needed. It informs each peripheral of the status of its paired device whenever there is an operation that may affect the synchronization.

Audio packet format and timing

Converting audio frames into packets, lets the peripherals derive timing. The implementation of the audio packet can be realized in a few basic rules:

  • The audio frame should match the connection interval in time. If the connection interval is 20ms and the sample rate is 18 kHz, then the audio frame shall contain 360 samples.
  • Sample rates are restricted to multiples of 8kHz, to have integer samples in a frame irrespective of the connection interval.
  • A sequence byte is added prior to audio frames. This sequence byte use for counting and allow the peripheral to detect buffer mismatch.
  • An audio frame always fit into a single LE packet. The audio frame is transmitted as a separate L2CAP packet.

payload + 1 (sequence number) + 6 (4 for L2CAP header, 2 for SDU)

Starting and stopping an audio stream

Before starting an audio stream, the central inquiries the peripheral devices and establishes a common denominator codec. A connection update is issued to switch the link to the parameters required for codec and then the central and the peripheral host wait for the update complete event.

Restart the encoder and reset the packet sequence. The peripheral takes the first audio packet i.e. sequence number 0 and plays it. During streaming, a replica should be available at every connection, even though its latency may be non-zero.  

The central issue a Stop command to end the audio stream. After this, the peripheral does not need to be available on every connection event. When the central is not streaming, it should still be connected to LE, for the GATT services.

The peripheral does not issue a connection update to the central. To save power, the central issue a connection update to the peripheral when it is not streaming audio.