Wearable and hearable OEM platform teams

Wake-Word-Free Addressee Detection for Wearables.

The body-worn mic hears the whole world.

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.

Both a device command and a social aside reach the always-on on-body mic Two speech types converge on the on-body microphone: a command directed at the device (lime, intended) and a social aside to a colleague or patient (gray, not intended). With no addressee gate, the voice assistant activates on both, producing wrong activations, social embarrassment, and risk to enterprise pilots. Command to device the intended interaction Social aside to a colleague or patient On-body mic (always on) Voice assistant, no addressee gate Activates on both Wrong activations. Social embarrassment. Enterprise pilot at risk.
Lime marks the device command. The social aside looks identical to the mic. Without an addressee gate both reach the voice agent and both can trigger a response.

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 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.

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.

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.

How SAA routes only addressed audio from the on-body mic On-body mic audio containing all speech in range streams left to right into the SAA gate. SAA decides in real time, before ASR runs, whether speech is addressed to the device. Addressed audio is forwarded to the existing ASR and model via a lime-highlighted path. Audio that is not addressed, or uncertain, is blocked; the system fails closed and does not forward it. On-body mic audio all speech in range SAA addressee decision real time ยท pre-ASR Addressed to your ASR and model Not addressed fails closed not forwarded
SAA sits before ASR. The addressee decision is made at the hosted inference endpoint. Addressed speech is forwarded; everything else, including anything uncertain, stops at the gate.
01

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.

02

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.

03

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.

04

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 licensing

access

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 eval

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
Noise cancellation and AEC
What it answersIs the audio cleaner?
When it runsPre-ASR
Decides who is addressed?No
Voice activity detection (VAD)
What it answersIs someone speaking?
When it runsPre-ASR
Decides who is addressed?No
Beamforming and direction-of-arrival
What it answersWhich direction did the sound come from?
When it runsPre-ASR
Decides who is addressed?No
Speaker diarization
What it answersWho spoke, after the fact?
When it runsPost-ASR
Decides who is addressed?No
Wake word detection
What it answersWas the trigger phrase said?
When it runsPre-ASR
Decides who is addressed?Phrase only
Speaker ID
What it answersIs this a known voice?
When it runsPre-ASR or post-ASR
Decides who is addressed?No
SAA addressee detection
What it answersIs the device being addressed, right now?
When it runsPre-ASR, real time
Decides who is addressed?Yes
Bottom line

Addressee detection that keeps unaddressed audio off your stack.

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.

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.

We do not share your information. See our privacy policy.