Developing Auracast™ Receivers
with an Assistant Application for
Legacy Smartphones
Author: Market Development
Version: 1.0
Revision Date: 16 February 2024
This document describes a standards compliant approach for how
Auracast™ receivers (earbuds, hearing aids, headphones, and
speakers) can be designed to work with a stand-alone Auracast™
assistant application, and satisfy user requirements to join an
Auracast™ broadcast using a legacy smartphone. Following this
approach can help accelerate the market adoption for Auracast™
broadcast audio and increase the likelihood users can immediately
take advantage of Auracast™ broadcast audio with new receivers.
2
Table of Contents
1. Introduction ............................................3
1.1 Nomenclature 4
2. Auracast™ Assistants – Finding and Joining an
Auracast™ Broadcast .....................................5
3. The Basics of Bluetooth LE Audio Broadcast ...................7
3.1 The Broadcast Advertising Structure 7
3.2 Building an Auracast™ Broadcast Database 10
3.3 Coordinated Sets – Dealing With Pairs of Earbuds
and Speakers 13
3.4 Building an Auracast™ Assistant for Legacy Devices 13
4. Using Legacy Smartphones As Auracast™ Assistants ...........14
4.1 Auracast™ Receiver Requirements To Support Older Phones 15
5. Conclusion .............................................17
6. References .............................................18
3
1. Introduction
The Bluetooth Special Interest Group (SIG) has released a groundbreaking audio innovation that will
change the way we engage with each other and the world around us. Auracast™ broadcast audio,

from sharing your audio and unmuting silent TVs to helping you hear your best in any environment.




• Auracast™ receivers (i.e., earbuds, headphones, hearing aids, speakers, etc.)
• 
stand-alone systems
• Auracast™ assistants, which let a user choose which Auracast™ audio stream they want to
listen to



aids when these products are compatible with a user’s legacy device.
Auracast™ transmitters for personal and public spaces are also coming to market, initially as stand-
alone transmitters which plug into the audio outputs of TVs, A/V equipment, and phones.

join, and leave their preferred Auracast™ broadcast. This requires an Auracast™ assistant, which
acts as a client for your Auracast™ receiver. In the future, this client functionality will be built into
Auracast™ enabled smartphones, tablets, watches, and PCs, but it will take time for these devices
to come to market with native capabilities. However, manufacturers of hearing aids, earbuds, and
headphones do not need to wait. Auracast™ assistant functionality can be provided by designing
earbuds, headphones, and hearing aids to work with stand-alone Auracast™ assistant applications





transmitters and audio applications.
The attraction of the new Auracast™ use cases cannot be understated. Companies at the forefront of

of audio applications.
back to contents
In this document, we will look at how to combine new Auracast™ receivers with applications that
can run on legacy smartphones to accelerate the market, letting you ship Auracast™ earbuds today,
increasing market reach, and growing user awareness.
1.1 Nomenclature

three devices that comprise the Auracast™ ecosystem. As using all of these can be confusing when
providing an overview, this document uses the generic, descriptive names of Auracast™ transmitter,
Auracast™ receiver, and Auracast™ assistant. These are used to describe both the physical devices



[1], the Public Broadcast

[2] [3]
[4][5].
Name Includes the role of Specication
Auracast™ transmitter Broadcast Source
Public Broadcast Source
Initiator
Broadcast Media Sender
BAP 2.2.2.1
PBP 3.1
CAP 2.1.1
TMAP 3.5.2
Auracast™ receiver Broadcast Sink
Public Broadcast Sink
Acceptor
Hearing Aid
Broadcast Media Receiver
BAP 2.2.2.2
PBP 3.2
CAP 2.1.2
HAP 3.2
TMAP 3.5.2
Auracast™ assistant Broadcast Assistant
Public Broadcast Assistant
Commander
BAP 2.2.2.3
PBP 3.3
CAP 2.1.3
Table 1.1 Underlying specication roles covered by the Auracast™ terminology in this document.
4
back to contents
5
2. Auracast™ Assistants – Finding and Joining an Auracast™ Broadcast

scanning task of Auracast™ assistant functionality into the receiver provides a way for the user to
easily select and join an Auracast™ stream without having to buy a new smartphone.
The basic philosophy behind Auracast™ broadcast audio is that Auracast™ receivers sit in a “sea”

and start, stop, or change reception at any time. It’s similar to the way we change live TV or radio
programmes by pressing a button on a remote control or selecting a station on a screen. Each person


location or venue.
As earbuds, headphones, and hearing aids generally have a very limited user interface, the easiest
way to make a choice is to use another device which has a richer interface. That may be an
application on a phone, a remote control, a smartwatch or some other product. These devices use a

Auracast™ assistant.



user selects one of these, the Auracast™ assistant acts as a client, instructing the receiver (the
headphones) to synchronise to the appropriate broadcast stream from that transmitter, at which point
the audio is rendered.
Available Auracast Broadcasts:
London Transport Stop J
London Transport Stop H
The Pizza Room
Mess Cafe
London Transport Stop I
Dave’s Laptop
Lori’s Phone
Advertising available
broadcasts
Transmitting audio
streams
Figure 2.1 The basic Auracast™ topology
back to contents
6
At no point does the audio broadcast go through the phone – the broadcast from the transmitter is
picked up directly by the receiver. In the case of pairs of receivers, like earbuds, hearing aids and
speakers, each device will receive the appropriate stream – either left or right. This topology means
the audio stream is totally independent of whatever type or brand of Auracast™ assistant is being
used. A secondary advantage of this approach is that the design and implementation of an Auracast™


users can choose whichever works best for them.
If there were only one audio stream within range, receiving it could be a simple and intuitive user

install multiple Auracast™ transmitters. You can easily imagine a bar or gym having multiple TVs

listen to the appropriate audio stream of their choice. At home, your TV might broadcast a dialogue
enhanced channel for listeners with hearing loss alongside the standard stereo audio streams. A
conference venue could provide alternate language translations in separate streams, as could a


broadcasts is why we need the Auracast™ assistant.
Finding all of the Auracast™ transmitters which are currently broadcasting uses a process called
scanning, where a Bluetooth device looks for all of the information that the transmitters are
advertising about their audio broadcasts.
Figure 2.1 shows a smartphone doing the scanning, but as we noted in the introduction, it will take
time for these devices to come to market with native capabilities, as scanning for this information

version 5.2
[6]

by how to design Auracast™ earbuds to support scanning on behalf of legacy smartphones. This

accelerate the market for Auracast™ broadcast audio. It’s an approach which is fully compatible with
future Auracast™ devices.
back to contents
7
3. The Basics of Bluetooth LE Audio Broadcast

needs to be implemented in earbuds, headphones, hearing aids, and speakers. Bluetooth LE Audio


Public
Broadcast Profile (PBP)Auracast™ Simple Transmitter Best Practices Guide, and
the Brand Guide for Bluetooth Trademarks

audio applications. Before looking at the details of an Auracast™ broadcast audio implementation, we
need to provide a bit of background about how Bluetooth LE Audio broadcasts work, as it is totally


applications is that no connection is required between a broadcaster and the speakers, hearing aids,
earbuds, or headphones which receive and render the audio. (In this document, we’ll collectively

concerned, they’re all the same.) The Auracast™ transmitter has no idea whether anything is listening
to what it sends – any number of Auracast™ receivers can listen at any time – the only requirement is
that they are within range of the transmitter.
Because there’s no connection between the devices, a new mechanism has been designed to let all
of the Auracast™ receivers know that there is something out there to listen to. This is accomplished
by the Auracast™ transmitter “advertising” information about itself and its streams, along with

transmitting. These advertisements include information such as the audio content, its language,
codec information, the audio quality, whether it’s mono or stereo, and so on. Some of this is in the


3.1 The Broadcast Advertising Structure
An Auracast™ transmitter can transmit multiple audio streams. They may be mono, stereo, multiple


advertisements. Between them, they convey all of the information about what the broadcast streams



the Broadcast Audio Scan Service (BASS) [7]Figure 3.1 shows

back to contents
88
back to contents
Auracast™ related data elements they contain. The Metadata LTV structures for Program_Info and

[8].
ADV_EXT_IND
AUX_ADV_IND
AUX_SYNC_IND
BIG
AD_Types
Appearance Value (CSS)
Local Name (CSS)
Broadcast Name (PBP)
« Broadcast Audio Announcement » (BAP)
« Public Broadcast Announcement » (PBP)
BASE
« Basic Audio Announcement »
(BAP)
(BAP)
Program_Info LTV
Language LTV
(AN)
(AN)
AuxPtr
SyncInfo
Advertising Channels
Periodic
Extended
Primary
BIGInfo (Core)
BIGcInfo
Figure 3.1 The structure of extended and periodic advertisements in Bluetooth LE Audio,
showing the key elements used for Auracast™.

database of relevant broadcasts by scanning for the advertisements. They do this by working through
advertisements from Auracast™ transmitters in range, looking at which are relevant, and storing that
Figure 3.2.


• Delegate the task to Auracast™ assistants which are capable of scanning,
• Do the scanning itself and notify the Auracast™ assistant of the results, or
• Perform any combination of scanning together with one or more Auracast™ assistants
1 LTV is an industry abbreviation for Length / Type / Value, which is a triplet of structured information used to exchange
metadata between devices.
9
Normally, the scanning is initiated by a user action, which may be a button press on an earbud, or an
action on an Auracast™ assistant application or device. As scanning can be relatively power hungry,
it should only be performed when the user initiates it and should be terminated at the point when the

assistant which is capable of scanning on its behalf, it is recommended to delegate the scanning task
to save power. Auracast™ assistants and Auracast™ receivers work together during this process to
create a database of available Auracast™ streams.
Look for a broadcaster
Determine if it’s of interest
Check QoS, Name, Contents, etc.
Decide which streams are relevant
Left / Right / Mono, Language, etc.
Synchronize to chosen stream,
or add to broadcast database
New Broadcaster Found
Broadcast of interest
Streams of interest
Not relevant
Not relevant
Primary
Advertisements
Extended
Advertisements
Periodic
Advertisements
Implementation
Conguration
Figure 3.2 The sequence of acquiring information about relevant broadcasts
Each device involved in scanning will start by looking for primary advertisements. If they contain the


advertisement, inspecting the Public Broadcast Announcement to determine if the streams have a
format they can decode. If they do, the scanner moves to the periodic advertisement, looking for
more details about each stream. Streams which meet policies set by the Auracast™ receiver will then
be written to the database before the scanner moves on to look for more Auracast™ broadcasts, or a
2 The presence of a Public Broadcast Announcement means that a broadcast is present which is likely to meet all of the
Auracast™ interoperability requirements. If the Public Broadcast Announcement is not present, the scanner should look
for a Broadcast Audio Announcement and then examine the details in the associated periodic announcement to
determine if there is a broadcast stream it can receive and render.
back to contents
10
decision is made to synchronise to one of the Auracast™ broadcasts that has been found. The policies

from the Auracast™ receiver’s settings.

discovered broadcasts is stored. This is located in the Auracast™ receiver, where the information is
stored in multiple instances of the Broadcast Receive State characteristic.
3.2 Building an Auracast™ Broadcast Database
Support for the Broadcast Audio Scan Service (BASS), is mandatory on all Auracast™ receivers. It
mandates the presence of two characteristics which are implemented to support and populate this
database of Auracast™ transmitters – the Broadcast Receive State characteristic and the Broadcast
Audio Scan Control Point characteristic. The data itself, along with the current synchronisation status
(i.e. which stream the earbud is listening to) is stored in multiple instances of the Broadcast Receive
State characteristic. Auracast™ assistants can populate these instances by writing to the Broadcast
Audio Scan Control Point characteristic with information on each new Auracast™ transmitter they


stream. If the Auracast™ receiver is scanning, it can populate and update these
instances autonomously.
When the Auracast™ assistant is used to choose a stream, it will write to the Broadcast Audio
Scan Control Point characteristic to request that the Auracast™ receiver starts or stops listening to

particular instance, initiating the synchronisation and rendering process.
Auracast™ assistants can read the Broadcast Receive State characteristic instances at any time to
determine the current status of the Auracast™ receiver.
There will always be one instance of the Broadcast Receive State Characteristic for the stream or
streams that an Auracast™ receiver is currently rendering. Generally, there will be further instances
for streams that it knows about, which it stores in case it wants to swap to one of those in the future.

select one of them to synchronise to the stream (or streams) which it contains. Once again, it can do
this autonomously, or be directed to do it by a selection made on an Auracast™ assistant.
At least one device – either the Auracast™ receiver or an Auracast™ assistant – must be scanning
to populate the Broadcast Receive State characteristic instances. However, the operations on the
characteristics, either reading them or updating them to start or stop reception, are normal GATT
characteristics. This means that any device which supports Bluetooth LE can read and write them,

back to contents
11
There’s a lot of data which is included in each Broadcast Receive State characteristic. Table 3.1


are mandatory.)
Field Description
Source_ID
3
A local, unique reference for each Broadcast Isochronous Group (BIG)
4
, generated

Receive State characteristic for each Auracast™ transmitter that the Auracast™
receiver is aware of.
Source_Address The Bluetooth address of the Auracast™ transmitter.
PA_Sync_State 

0x00 = Not synchronised to the periodic Advertising train for this BIG
0x02 = Synchronised to the periodic Advertising train for this BIG
(Only one instance of the Broadcast Receive State characteristic would normally have

received.)
Encryption Shows whether the stream is encrypted, and whether the Auracast™ receiver needs a
code to decrypt it.
BIS_Sync_State * 
currently receiving, e.g. Left, Right, Mono, or Left and Right. (Normally, an Auracast™
receiver will only be receiving audio from one BIG.)
Metadata * A variety of user readable information, which can be used to populate the user
interface of an Auracast™ assistant.
Broadcast_Name The name of the Auracast™ transmitter, such as Pub TV #1
Program_Info 
etc.
Language The language of the stream
* The BIS_Sync_State and Metadata are contained in arrays – one for each subgroup in the BIG.
Table 3.1 The main Auracast™ related components of the Broadcast Receive State characteristic
3 In the case of a coordinated pair, such as a pair of earbuds, speakers or hearing aids, each will assign their Source_ID
values independently. Auracast™ assistants need to keep track of these dierences.
4 Each Broadcast Receive State characteristic relates to a dierent Broadcast Isochronous Group (BIG) and includes
information about every Broadcast Isochronous Stream (BIS) within that BIG. If an Auracast™ transmitter is
broadcasting two dierent BIGs, then each would be represented by a separate Broadcast Receive State characteristic
with a dierent Source_ID.
back to contents
12
The full set of Broadcast Receive State Characteristics
is held in the Auracast™ receiver, but it makes sense
for every Auracast™ assistant to keep a local copy, so
that they know what the Auracast™ receiver knows.
They can periodically read the Broadcast Receive
State characteristics, or set the Broadcast Receive
State characteristic to notify them whenever the status
changes on the Auracast™ receiver. These changes
may be triggered if the Auracast™ receiver is scanning
independently, or because it has more than one
Auracast™ assistant scanning on its behalf.
This may initially seem complicated, but Figure 3.3


user interface implemented as a stand-alone phone
application. It displays a list of the Auracast™
broadcasts which it has found within range using the
human readable metadata elements. Additionally, by
reading the Broadcast Receive State characteristics
on the Auracast™ receiver, it can determine whether
the Auracast™ receivers are currently receiving one
of these, and if so, highlight it. The display can also
indicate whether any of the streams are encrypted.
If the user wants to make a change, they just need to
tap the appropriate Broadcast_Name in the list and
the Auracast™ assistant will write to the Broadcast
Audio Scan Control Point characteristic, updating the

the earbud to change to the new stream. As the number of Auracast™ transmitters increases, more
information may need to be presented to the user to make a more informed decision.
The user interface is independent of whether the phone is scanning, or whether the scanning is being

from the Broadcast Receive State characteristics of the Auracast™ receiver with which it is paired.
Figure 3.3 also highlights the fact that the device which is operating as an Auracast™ assistant can
control other features like volume, mute and balance.
Available Auracast Broadcasts:
London Transport Stop J
London Transport Stop H
The Pizza Room
Mess Cafe
London Transport Stop K
L RBalance
Figure 3.3 A typical user interface for a phone
application based Auracast™ assistant
back to contents
13
3.3 Coordinated Sets – Dealing With Pairs of Earbuds and Speakers
If you have two Auracast™ receivers, as is the case with earbuds, hearing aids, and sets of speakers,
the Auracast™ assistant will write to the relevant Broadcast Audio Scan Control Point characteristics
of each, as it will know that they are members of a coordinated set. Auracast™ assistants know
whether they are dealing with a single headset or a pair of earbuds or hearing aids, because when

then the Auracast™ assistant will look for both members and associate with both of them. From that
point on, it will always treat them as a pair, making sure they both receive audio streams from the
same Auracast™ transmitter.
After pairing, an Auracast™ assistant should also read the Published Audio Capability (PAC) records
[9] of each member of the coordinated set, so that it knows which one requires a right stream and
which requires a left stream, or whether they would both prefer mono. With this information, an

Auracast™ receiver will notify all of its Auracast™ assistants of any changes that occur, so that all of
them stay up to date with the current status.
3.4 Building an Auracast™ Assistant for Legacy Devices
It’s easy to miss the importance of an Auracast™ assistant. Auracast™ assistants provide most of the

• Discovering what, and how many Auracast™ broadcasts are within range
• Determining whether each broadcast is relevant and displaying it to the user
• Providing a simple user interface for a user to start and stop receiving an Auracast™ broadcast
• Adding an easy way to adjust volume.
An Auracast™ enabled smartphone or watch is an obvious choice for an Auracast™ assistant, as it is
generally always with the user. However, the functionality can also be shared between earbuds and

back to contents
14
4. Using Legacy Smartphones As Auracast™ Assistants
Manufacturers of hearings aids, earbuds, and headphones should not wait for smartphones to
natively support the Auracast™ assistant functionality. The Auracast™ assistant functionality needed
by users can be supported in earbuds, headphones, hearing aids, and speakers, interacting with
familiar legacy smartphones that do not include native Auracast™ assistant functionality.
To operate with an earlier generation of smartphones, which don’t support scanning for
advertisements, we have to move the scanning task to the Auracast™ receivers. All Auracast™
receivers must be able to scan for these advertisements. That’s a mandatory requirement in the Basic

places where there is only one Auracast™ transmitter, simple scanning and joining direct from the

multiple Auracast™ broadcast audio streams within range, in a single location.
To use an older phone to display multiple Auracast™ broadcasts that are available, an Auracast™

available to an application on the smartphone. It does this using a simple Bluetooth GATT procedure
(which is the basis of all Bluetooth LE applications and is supported by almost every smartphone
made in the last ten years).
The phone application can either read the earbud’s Broadcast Receive State characteristics or


particular broadcast, synchronise to it and start rendering it.
Available Auracast Broadcasts:
London Transport Stop J
London Transport Stop H
The Pizza Room
Mess Cafe
London Transport Stop I
Dave’s Laptop
Lori’s Phone
Scan
Notify
Write Write
Figure 4.1 Using a legacy phone as Auracast™ assistant for a pair of earbuds
5 Which means they are using silicon that do not support Bluetooth Core Specication version 5.2 or later, or do not
contain a Bluetooth LE Audio host stack.
back to contents
15
Figure 4.1 puts all of this together, showing how a pair of Auracast™ earbuds can use a standalone



allowing the phone application to replicate and display the list of the Auracast™ transmitters that

phone application and the phone writes to the Broadcast Audio Control Scan Point on each earbud,
instructing them to synchronise to that Auracast™ transmitter.


will have recognised that they are members of a coordinated set, so the application knows that it
must send any instructions to both of them. It will also have discovered basic information about each
of the earbuds by reading the Published Audio Capability (PAC) records on each of them. These

a broadcast stream to listen to, the Auracast™ assistant application on the phone will use this
knowledge to select the correct stream information in its Broadcast Audio Control Scan Point write,
directing each earbud to the correct broadcast stream.
4.1 Auracast™ Receiver Requirements To Support Older Phones
The industry does not need wait for new smartphones before supporting Auracast™ broadcast audio
in new products. To ensure current and future compatibility with applications on smartphones, there
are some design requirements which Auracast™ receivers need to adopt, whether they’re earbuds,

• They need to support more than one Broadcast Receive State characteristic. BASS places
a requirement on an Auracast™ receiver, mandating the presence of at least the same number
of Broadcast Receive State characteristics as the number of audio streams that it can receive.

applications, the Auracast™ assistant should be designed to support a sensible number

become available. In the short term, only a few devices may be within range, but as the
popularity of Auracast™ broadcast audio grows, so will the number of discovered devices.
As an Auracast™ transmitter can have a range of 100m or more, it is recommended that at
least 10 instances of the Broadcast Receive State characteristic are supported.
• Auracast™ receivers need to consider their power management if they are performing
scanning. In most cases, scanning by an Auracast™ receiver should be restricted to a short
period after a user action, such as pressing a button. Typically, scanning should be

Auracast™ transmitter, whether that decision is made locally, or by an Auracast™ assistant.
back to contents
16
• Software application designers should be aware that Auracast™ receivers may not have
completed their scan sequence when the application is started. They should register for

their displayed information as additional Auracast™ transmitters are discovered by the
Auracast™ receiver.
• Auracast™ receivers should check whether fully featured Auracast™ assistants capable of
scanning are available. If they are, they should delegate the scanning activity to these

which they can terminate their own scanning.

phones that do not support the scanning requirements of Bluetooth LE Audio.
Providing a simple phone application means that Auracast™ transmitters can be rolled out in volume

make sure that their Auracast™ receivers can perform Auracast™ scanning and use the information
they gather to populate their Broadcast Receive State characteristics. As long as that happens,

upgrade their current phone.
The process described above is based on characteristics which must be implemented in every
Auracast™ receiver. This means that Auracast™ assistant applications developed according to this
approach will be compatible with all Auracast™ receivers which also follow them. The Auracast™
receivers will also be forward compatible with future Auracast™ assistants, without the need for
users to make any changes to their devices.
back to contents
17
5. Conclusion


alone Auracast™ assistant application. With dual-mode receivers, we encourage manufacturers

for unicast. This way, users can immediately take advantage of the new capabilities of Auracast™
broadcast audio without the requirement to update their smartphone.



phone applications.



development timescales.
back to contents
18
6. References
[1] Basic Audio Profile (BAP)
[2] Public Broadcast Profile (PBP)
[3] Common Audio Profile (CAP)
[4] Telephony and Media Audio Profile (TMAP)
[5] Hearing Access Profile (HAP)
[6] Core specification 5.2 or later
[7] Broadcast Audio Scan Service (BASS)
[8] Assigned Numbers
[9] Published Audio Capabilities Service (PACS)
back to contents