All Big Five Hearing Aid Makers Embrace Auracast: How Bluetooth Broadcast Audio Is Reshaping Hearing Accessibility

From "Better Hearing" to "Connected Hearing": The Auracast Inflection Point

For decades, the hearing aid industry's innovation story was told in a narrow vocabulary: channels, compression strategies, feedback cancellation, receiver-in-canal versus behind-the-ear form factors, and battery chemistry. Those remain important, but they describe a product category optimized around amplifying the right sound. The Bluetooth SIG's Auracast broadcast audio initiative changes the question entirely. The question is no longer only "can this device make speech intelligible?" but "can this device join the audio fabric of a public space, a car cabin, a lecture hall, or a multi-screen home without a dedicated loop system, a proprietary streamer, or a smartphone in the middle?"

The commercial significance is straightforward: when all five major hearing aid manufacturers — Demant (Oticon), Sonova (Phonak), WS Audiology (Signia/Widex), GN Hearing (ReSound), and Starkey — ship Auracast-capable products, the feature stops being a differentiator and becomes table stakes. That transition is the moment buyers should start paying attention, because it forces every vendor to compete on implementation quality, battery behavior, assistive-listening ecosystem support, and real-world usability rather than on a checkbox.

This article is written for the practical evaluator: the audiologist specifying a fitting, the procurement lead equipping a venue, the embedded developer integrating LE Audio, and the informed consumer comparing quotes. It focuses on what is verifiable in the Bluetooth specifications, what is observable in field use, and where the genuine trade-offs lie.

What Auracast Actually Is (and What It Is Not)

Auracast is the Bluetooth SIG's consumer-facing brand for broadcast audio built on the LE Audio architecture. Technically, the broadcast path is defined by the Basic Audio Profile (BAP) broadcast procedures, coordinated by the Common Audio Profile (CAP), which "specifies procedures to start, update, and stop unicast and broadcast Audio Streams on individual or groups of devices using procedures in the Basic Audio Profile (BAP)." CAP v1.0.1, adopted by the Bluetooth SIG Board of Directors on 2025-02-11, is the profile that lets a source and a set of sinks agree on how a broadcast stream is started, updated, and stopped, and it also references the Common Audio Service (CAS) and the volume/microphone control profiles (VCP, MICP) used to manage groups of devices.

The discovery and joining side is handled by the Broadcast Audio Scan Service (BASS). Per the specification, BASS "is used by servers to expose their status with respect to synchronization to broadcast Audio Streams and associated data, including Broadcast_Codes used to decrypt encrypted broadcast Audio Streams." In plain terms: a hearing aid (or earbud, or phone acting as an assistant) can act as a BASS server and tell a client — typically a phone or a remote control — which broadcast it is synchronized to, and provide the Broadcast_Code needed to decrypt an encrypted stream. The client can also "observe and/or request changes in server behavior," which is how a phone app can steer a hearing aid from one Auracast stream to another.

This architecture matters for evaluation because it separates three capabilities that buyers routinely conflate:

• Broadcast reception — the hearing aid itself can synchronize to and decode an Auracast stream (BAP broadcast sink role).
• Broadcast assistance — a phone or accessory can scan for broadcasts, obtain Broadcast_Codes via BASS, and hand the stream to the hearing aid. This is often how encrypted venues are joined.
• Broadcast transmission — a device can originate a stream (BAP broadcast source). Hearing aids almost never do this; venues, TVs, and phones do.

What Auracast is not: it is not a replacement for telecoil in every jurisdiction, it is not guaranteed to work with every "Auracast-ready" logo you see on a venue door, and it is not a single global standard for encryption key distribution. Those gaps are where real-world evaluation gets interesting.

The Five-Maker Landscape: What "Support" Means in Practice

Announcing Auracast support and shipping a robust implementation are different things. Across the Big Five, the pattern has been: flagship RIC and custom products get LE Audio/Auracast first, followed by a firmware or app update cycle, with the phone ecosystem determining when the feature is actually usable. The practical evaluation criteria are consistent regardless of brand:

• Firmware maturity: Does the shipping firmware include broadcast sink support, or is it "coming soon"? Ask for the exact firmware version and the release note that lists Auracast.
• Phone dependency: Can the aid join an unencrypted broadcast directly via its own controls, or does it require the vendor app and a compatible phone?
• Encrypted venue support: Does the app implement BASS client behavior to retrieve Broadcast_Codes, and is the venue's key distribution compatible?
• Multi-stream handling: Can the aid hold a unicast connection (phone call, TV streamer) while a broadcast is available, and how does it arbitrate?
• Battery impact: Broadcast reception is a continuous radio + DSP load. Measure it, don't trust the datasheet.

Because vendor roadmaps shift, the responsible approach for a buyer is to demand a demonstration in the actual venue or a simulated one, with the actual phone the user owns. A feature that works only on a flagship Android phone with a specific OS build is not the same product as one that works on the user's three-year-old handset.

Scenario 1: Public Spaces — Airports, Stations, Theatres, Places of Worship

This is Auracast's headline promise: walk into a space, see the broadcast in a list, tap once, and hear the announcement or the stage feed directly in your aids at your own volume and EQ. The technical enablers are BAP broadcast and BASS-assisted joining. The practical enablers are venue infrastructure and signage.

What to test. In a large hall, evaluate:

• Discovery latency: time from opening the broadcast list to the stream appearing. Good implementations surface streams in a few seconds; poor ones require a manual rescan and can miss low-duty-cycle advertisers.
• Join time: time from selection to audible audio. Expect a few seconds for synchronization and codec setup; anything approaching ten seconds feels broken in a live announcement context.
• Range and robustness: walk to the back of the hall and into the lobby. Broadcast uses periodic advertising and an isochronous stream; range is broadly comparable to other 2.4 GHz LE links but is sensitive to body shielding and venue RF congestion.
• Volume independence: confirm the user's volume control affects only their aids, not the venue feed. CAP's group volume procedures (via VCP) are designed for this, but implementation quality varies.
• Encryption handling: in venues that encrypt, confirm the app retrieves and applies Broadcast_Codes without exposing them in logs or requiring manual entry.

Venue-side reality check. A venue that advertises "Auracast available" must have a transmitter, an antenna plan, and a key-management policy. Ask three questions before trusting the signage: Is the stream encrypted? How does a user obtain the code (app, QR code, front desk)? Is there a fallback (telecoil loop, FM, or a loaner receiver) for users whose aids lack the feature or whose phones are incompatible? The last question is the one that separates accessibility compliance from marketing.

Scenario 2: The Car Cabin — An Automotive Angle That Actually Matters

The automotive category is where Auracast's business case is most underappreciated. Modern vehicles already contain multiple audio zones: front and rear infotainment, rear-seat entertainment, navigation prompts, and increasingly, passenger-specific media. Today, hearing aid users in a car typically face a choice between streaming everything through a single phone connection (which mixes navigation, calls, and media) or relying on cabin acoustics (which reintroduces the exact problems the aids were fitted to solve).

Auracast offers a cleaner model: the vehicle's infotainment head unit or a rear-seat entertainment module acts as a broadcast source, and each passenger's aids join the stream they want. Passengers with normal hearing use the speakers or their own headphones; hearing aid users join the broadcast directly. This is a genuine accessibility improvement, not a gimmick, because it decouples the hearing aid user's audio from the cabin's single mix.

Evaluation points for automotive integration:

• Source role support: confirm the head unit implements BAP broadcast source and CAP procedures, not merely a proprietary "hearing aid" mode.
• Latency budget: broadcast audio has an inherent latency. For media playback this is tolerable; for lip-synced rear-seat video it must be managed. Ask for the measured end-to-end latency and whether the source compensates video timing.
• Multi-zone isolation: verify that two passengers can join two different broadcasts without crosstalk, and that joining a broadcast does not mute the cabin speakers for everyone else.
• Power and thermal: continuous broadcast transmission in a parked vehicle is a real 12V load; confirm the vehicle manages it with ignition state.
• Pairing and re-join behavior: the best implementations remember a passenger's aids and re-join automatically on the next trip; the worst require a full scan every time.

For fleet buyers — shuttle services, accessible transport, ride-hail — the procurement question is whether the vehicle's audio system exposes a standards-based broadcast rather than a vendor-specific app. Standards-based is the only version that survives a mixed fleet of hearing aid brands, which is exactly the situation every operator faces.

Scenario 3: Multi-Device and Multi-User Listening at Home

Auracast's second commercial pillar is multi-device connectivity. The classic pain point: a hearing aid user wants TV audio, a phone call, and a tablet video, and the aids can hold only a limited number of unicast links. Broadcast changes the topology. A TV or a small transmitter can broadcast; any number of aids and earbuds can join; the phone remains available for calls.

What good looks like:

• TV as broadcast source: the TV or a set-top transmitter advertises a stream; the aids join without a dedicated streamer box. This removes a device, a power supply, and a pairing ritual from the user's life.
• Simultaneous unicast + broadcast: an incoming call should pre-empt or duck the broadcast cleanly, then return. Test this explicitly — it is the most common failure mode.
• Multi-user: two hearing aid users (or a user plus a partner with earbuds) join the same TV broadcast at independent volumes. This is a strong selling point for couples where one partner has hearing loss.
• Privacy: an unencrypted home broadcast is receivable by anyone in range. For a house, that is usually acceptable; for an apartment building, consider encryption and Broadcast_Code management via the app.

Software and Hardware Comparison: Where the Differences Hide

Because all five makers now support Auracast, the comparison shifts to implementation. The table below is a framework for evaluation rather than a brand ranking; fill it in with the specific models and firmware you are considering.

• Radio and antenna: LE Audio broadcast reception is a continuous load. Devices with well-tuned antennas and efficient radio scheduling show materially better battery life and range. Ask for measured current draw during broadcast reception, not just "up to" battery figures.
• DSP headroom: broadcast audio arrives as an LC3 stream; the aid must decode, apply gain and compression, and mix with any alert sounds. Devices with limited DSP headroom may degrade sound quality or drop features when a broadcast is active.
• Firmware update path: can the aid be updated over the air, or does it require a clinic visit? Auracast is a moving target (CAP and BASS were both revised to v1.0.1 in February 2025), so updateability is a long-term value factor.
• App quality: the phone app is the BASS client in most deployments. Evaluate scan reliability, stream naming, code entry, and error messages. A cryptic "connection failed" is an accessibility failure.
• Ecosystem breadth: does the maker's accessory line (TV streamers, remote mics) also support Auracast, or only proprietary protocols? Mixed support creates user confusion.

Performance Benchmarks You Can Actually Run

Vendor datasheets are not a substitute for measurement. The following benchmarks are reproducible with modest equipment and are the ones that predict satisfaction:

• Join latency: stopwatch from stream selection to first audible syllable, repeated ten times in the same location. Report median and worst case.
• Battery delta: full charge, then four hours of broadcast reception at typical volume versus four hours of quiet. The delta is the real cost of the feature.
• Range walk: in a venue, measure the distance at which dropouts begin, both line-of-sight and through a crowd. Repeat with the phone in a pocket versus in hand.
• Coexistence: with a phone call active and a broadcast joined, measure how quickly the call is answered and how cleanly audio returns afterward.
• Encrypted join: time to join an encrypted stream including code retrieval, and whether the code persists across sessions.
• Multi-user: two aids plus two earbuds on one broadcast; check for independent volume and no crosstalk.

For developers, the conformance angle is equally practical: CAP v1.0.1 and BASS v1.0.1 define the procedures and the attribute behavior. If your product claims Auracast support, your BASS server or client behavior should be testable against those specifications, and your broadcast source should follow BAP broadcast procedures. The Bluetooth Qualification Process is the mechanism that keeps the ecosystem interoperable; skipping it is how "works with my phone" becomes "doesn't work with yours."

Buying Guide: A Decision Framework

If you are a consumer replacing aids in the next 12 months: prioritize Auracast support, but verify it in person. Bring your own phone, ask the clinic to demonstrate joining a broadcast, and confirm the firmware version. Treat "Auracast-ready" without a working demo as a future promise, not a feature. If you frequently attend venues with loops, keep telecoil as a fallback — Auracast coverage is growing but not universal.

If you are an audiologist: add a broadcast test to your fitting protocol. Use a clinic transmitter or a phone-based source to verify join behavior, volume independence, and call pre-emption. Document the firmware version you validated so that a later update does not silently regress the feature. Counsel patients on the difference between direct join and app-assisted join, because that difference determines whether they can use the feature independently.

If you are a venue operator: specify standards-based Auracast, not a proprietary "assistive listening" mode. Require encryption with a documented code-distribution method, a fallback system, and signage that explains how to join. Budget for an RF survey; a single transmitter in a concrete hall is not a plan.

If you are an automotive OEM or Tier 1: treat broadcast source support as an accessibility requirement, not a premium audio feature. Define latency budgets for video sync, multi-zone isolation, and re-join behavior in the requirements document. Test with aids from more than one manufacturer — interoperability is the whole point.

Risks and Open Questions

Three risks deserve honest treatment. First, the phone bottleneck: many joining workflows depend on a companion app, and app quality varies. A user who cannot operate the app is locked out of encrypted venues. Second, encryption key distribution: BASS defines how Broadcast_Codes are exposed, but not how a venue tells a user the code. QR codes, front-desk scripts, and app integrations are all in use; there is no universal convention yet. Third, the "ready" label: marketing language outpaces firmware. The only defense is a demonstration with the user's own devices.

None of these undermine the direction of travel. They simply define the diligence a serious buyer should apply.

Bottom Line

The Big Five embracing Auracast is the moment hearing aids stop being a closed amplification system and become participants in a standards-based audio ecosystem. For users, the payoff is concrete: direct access to public-space audio, a cleaner multi-device topology at home, and a credible path to in-car audio that respects individual hearing needs. For the industry, the payoff is a shift in competition from proprietary lock-in to implementation quality — battery efficiency, join latency, encryption handling, and interoperability.

The practical recommendation is uniform across roles: demand a demonstration, measure the benchmarks that matter, and insist on standards conformance rather than logo compliance. Auracast is a genuine accessibility advance; the work now is making the shipped experience match the specification.

💬 Join the discussion on our forum: Share your thoughts or ask questions