Wearable and hearable OEM platform teams
Wake-Word-Free Addressee Detection for Wearables.
The body-worn mic hears the whole world.
The failure
The body-worn mic is always on, always in range of someone else's conversation.
Every ambient conversation on the floor, in the ward, or in the office is a false-trigger candidate.
A nurse turns to reassure a patient. The always-on mic picks up the aside, and the assistant fires aloud in the exam room.
false trigger
The device fires when the wearer is talking to someone else
The always-on mic cannot distinguish a social aside from a device command.
Without a gate, the assistant activates in front of colleagues and patients, and trust in the wearer drops.
enterprise procurement blocker
Ambient recording liability stalls regulated deployments
Compliance teams ask what audio is captured when unaddressed. That question stalls procurement.
The fix
The pre-ASR decision the legacy audio stack does not make.
Selective Auditory Attention (SAA) is a hosted, pre-ASR layer that decides in real time whether on-body mic speech is addressed to the device or to someone else.
Addressed audio is forwarded to your existing ASR and model. Everything else fails closed.
Research foundation
Measured on the multi-party conversational audio that wearables actually encounter.
SAA is measured on held-out multi-party sessions: audio-video fusion and audio-only (arXiv:2604.08412).
Two caveats: it fails closed under distribution shift, and cross-lingual recall is a known limitation.
performance
Reliable on audio and video fusion
Held-out multi-party sessions, including a video stream alongside audio.
performance
Reliable on audio-only
Real multi-speaker audio, no video stream required.
latency
Real-time decision, before STT
The routing decision returns before ASR begins, with no GPU required and no perceptible delay.
design principle
Fails closed by design
Ambiguous speech is suppressed, not forwarded. Under uncertainty, the default is silence, not a false activation.
coverage
Multi-party conversational environments
Covers multi-speaker interactions in clinical, field, and office settings. Coverage detail is scoped on a call.
enterprise readiness
Compliance angle: unaddressed audio does not reach your ASR or model
Audio not addressed to the device stops at the gate. A Data Processing Agreement is available for regulated deployments.
How it integrates
Where SAA sits in your wearable audio stack.
SAA inserts between the on-body mic and your ASR: no wake word, no on-device GPU, no changes to your hardware or model.
Audio in
Audio from the on-body microphone streams to the hosted SAA service before any ASR or model processes it.
No wake word required. No GPU on the device.
Addressee decision
SAA analyzes on-body mic audio and decides in real time who the speech is addressed to.
The decision does not depend on the content of the utterance.
Route only addressed audio
Only addressed audio reaches your ASR and model. Social asides and ambient room speech are suppressed.
Under uncertainty the system fails closed and forwards nothing.
Hosted, per-device, DPA available
SAA is hosted, licensed per device, with client SDKs in JavaScript/TypeScript and Python.
Embedded deployment is a separate enterprise license scoped on a call after an initial evaluation.
architecture
Pre-ASR, hosted, behind any model
SAA is model-agnostic: any ASR, any voice agent, no wake word, no GPU, no hardware changes.
The client SDK handles the audio handoff.
OEM licensingaccess
Eval tier is free. Licensing is per device.
Book a call to scope a deployment, or request an eval to run SAA on your own wearable audio before any commitment.
Request an evalWhy existing tools miss it
Every layer in the audio stack answers a different question, never "who is addressed?"
Without an addressee decision, every conversation the wearer has reaches the part of the pipeline that acts on it. SAA fills that gap.
| Layer | What it answers | When it runs | Decides who is addressed? |
|---|---|---|---|
| Noise cancellation and AEC | Is the audio cleaner? | Pre-ASR | No |
| Voice activity detection (VAD) | Is someone speaking? | Pre-ASR | No |
| Beamforming and direction-of-arrival | Which direction did the sound come from? | Pre-ASR | No |
| Speaker diarization | Who spoke, after the fact? | Post-ASR | No |
| Wake word detection | Was the trigger phrase said? | Pre-ASR | Phrase only |
| Speaker ID | Is this a known voice? | Pre-ASR or post-ASR | No |
| SAA addressee detection | Is the device being addressed, right now? | Pre-ASR, real time | Yes |
Addressee detection that keeps unaddressed audio off your stack.
Common questions
What wearable and hearable OEM platform teams ask before integrating.
What is addressee detection for wearables and how is it different from a wake word?
Addressee detection determines, in real time, whether speech at the on-body microphone is directed at the device or at another person in the environment. SAA makes this decision in real time, before ASR runs, and forwards only addressed audio to your stack. A wake word only detects a trigger phrase; it cannot determine whether the surrounding utterance was actually intended for the device. Addressee detection closes the gap that wake words leave open, and fails closed when uncertain.
Does a wake word already solve the addressee problem for wearables?
A wake word tells you that a specific phoneme sequence was spoken, not whether the utterance was actually directed at the device. In always-on wearable environments, a wearer quoting the trigger phrase to a colleague, reading aloud, or standing in a room where someone else says the phrase all register as activations. Wake words also require the wearer to prepend a phrase to every natural command, which breaks down in the professional and social settings where wearables are being deployed. SAA operates on the audio at the on-body microphone, working after a wake word fires or instead of one, and fails closed when uncertain.
Is audio processed on the device or in the cloud?
SAA runs as a hosted cloud service. Audio from the on-body microphone streams to the hosted service at server.attentionlabs.ai, and the addressee decision returns in real time through a thin client SDK. No model runs on the wearable hardware by default. Embedded deployment is available as a separate enterprise license for programs with strict power, privacy, or IP control requirements, and is scoped on a call after an initial evaluation.
What is the latency budget, and does this add load to the device?
The addressee decision returns in real time from the hosted service, before your ASR would have begun processing. No model runs on the wearable hardware in the default hosted configuration. The device-side cost is limited to the audio buffer handoff to the client SDK; no inference runs on the device. For programs where the hosted round-trip is unsuitable due to intermittent connectivity or power constraints, embedded deployment is available as a separate enterprise license.
How does SAA integrate into a wearable audio pipeline?
SAA sits between the on-body microphone and your ASR. Client SDKs in JavaScript/TypeScript and Python stream audio from your existing pipeline to server.attentionlabs.ai and return the addressee decision. The integration surface is a single audio buffer handoff and a binary or probability output. No change to your model, ASR, or UX layer is required.
What about ambient-recording liability and privacy compliance?
SAA is hosted and fails closed. Audio that is not addressed to the device is not forwarded to your ASR or model; it stops at the gate. This narrows the category of ambient capture that GDPR data minimization principles and HIPAA minimum-necessary rules require you to justify, which is a common blocker in enterprise wearable procurement. A Data Processing Agreement is available for regulated deployments.
Is embedded deployment available?
Embedded deployment is available as a separate enterprise license for programs that require it, for example where strict privacy architecture, intermittent connectivity, or power constraints make a hosted round-trip unsuitable. It is not the default public motion and is scoped on a call after an initial cloud evaluation.
Get in touch
Book a call or request an eval.
Tell us about your wearable or hearable platform. We evaluate SAA on your own audio and return scores for your team.
Or try the Cloud SDK to get a feel.
Last updated June 26, 2026