ASHA is a Bluetooth specification for hearing aids. This doc describes the API that BlueZ will expose to support ASHA.
ASHA support will be implemented within BlueZ. This is done to allow greater flexibility with regards to clients that want to use the profile implementation (the alternative being to have the profile implementation inside PipeWire).
This implementation will be used by PipeWire to support ASHA devices as output devices on Linux. The API between BlueZ & PipeWire will be similar to the existing one that is exposed as org.bluez.MediaEndpoint1.
The A2DP and BAP MediaEndpoint1 implementations are somewhat flexible, allowing clients to register endpoints, signal various supported configurations, and perform negotiation with the remote.
For ASHA, the peripheral exposes a set of GATT attributes providing device information and capabilities as well as commands to initialise/teardown streaming. Streaming occurs over a LE CoC (connection-oriented channel) socket.
At the moment, there are no real knobs for configuring streaming (a single codec and transport size are supported).
Applications registered with the Media1 interface are notified about new MediaEndpoint1 interfaces as with A2DP and BAP. The MediaEndpoint1 will have the ASHA profile UUID, and some properties that are ASHA specific.
<aside>
đź’ˇ The ASHA endpoint will not implement SetConfiguration(), and will instead directly expose a MediaTransport1 that can be Aqcuire()d to obtain the CoC socket file descriptor to start streaming.
</aside>
In the future, the endpoint may implement SelectProperties() if configuration of transport parameters is desired.
Device pairs can be identified by matching their “HiSyncId” GATT attribute (it will be the same for devices in a pair).
The expectation with a pair of hearing aids is that the central will send the audio data to both devices, with packets that should be played simultaneously having the same sequence number in the first byte.
Also included in the ability to specify the other device state while starting the streaming process, as well as in the middle of stream (for example, the other device might get disconnected mid-stream). We will need to decide whether this is managed within the BlueZ ASHA plugin, or if we wish to extend the DBus interfaces to allow the client to do so.
Each device in the pair will be exposed as an independent endpoint. Clients will be able to identify pairs by endpoint properties, choose how to group them. In PipeWire, we should be able to leverage the infrastructure for managing LE Audio device sets, though questions remain about rate matching independent channels.
The goal is to implement support for a single device first, and then do a second pass to support pairs.