Per-device addressee detection for OEM voice product teams
Always-listening devices must know who is addressing them.
SAA (Selective Auditory Attention) is a neutral, hosted pre-ASR layer.
The missing layer
VAD, wake words, and beamforming never ask who is being addressed.
Every always-listening device shares the same gap: the mic hears everyone, and nothing decides who it was for. In a home, a hospital corridor, a vehicle, or a service environment, most of the speech that reaches the microphone is not directed at the device.
Without that gate, false activations ship as a design constraint. A pilot that behaves in a quiet test room can misfire once it reaches a real room, and the alternative is absorbing the returns, rollback, and field complaints.
false activation
Bystanders trigger responses the user never asked for
Without an addressee gate, a bystander, a nearby conversation, or ambient noise can trigger a response.
Every false trigger wastes downstream compute and erodes the trust a voice product depends on.
build cost
Building this in-house takes years, not a sprint
It needs labeled multi-party audio for your device's acoustic conditions, a training pipeline, and ongoing calibration.
Most hardware teams have neither. SAA makes it a licensable IP block instead of a build.
The fix
A licensable addressee IP block that drops in upstream.
SAA is a hosted, pre-ASR layer that decides, in real time, whether speech is addressed to your device. Addressed audio routes to your ASR; everything else fails closed.
Research foundation
Built on our published technical paper.
SAA makes the addressee decision reliably across held-out, open-mic multi-party sessions (arXiv:2604.08412).
Two caveats apply: it fails closed under distribution shift, and cross-lingual recall is a known limitation under active work.
performance
Reliable on audio and video fusion
Held-out multi-party sessions. Published at arXiv:2604.08412.
performance
Reliable on audio-only
Real multi-speaker audio, no video stream. Same caveats apply as audio-and-video.
latency
Decision in real time
The routing decision is returned before ASR begins. No GPU required.
design principle
Fails closed by design
Ambiguous speech is suppressed, not passed through. The default is silence, not a false trigger.
Non-addressed audio is not forwarded to your ASR or model.
coverage
Multiple concurrent speakers
Handles multi-party environments with concurrent speakers, like a shared room, vehicle, or workspace.
signal model
Pre-ASR signal analysis; no language parsing
No wake word. Language-agnostic at the acoustic level.
Works with any microphone and any downstream ASR.
How it integrates
One upstream insert. Your microphone, ASR, and voice model stay unchanged.
SAA sits between your microphone and your ASR. Audio streams to the hosted service, a decision returns in real time, and only addressed audio proceeds.
Stream audio from the microphone you already ship
Audio streams from your mic to the hosted SAA service before ASR runs. No array or GPU required.
Thin client SDKs in JavaScript/TypeScript and Python connect to server.attentionlabs.ai.
Addressee decision
SAA analyzes audio pre-ASR, no wake word, and decides who the speech was addressed to.
Route only addressed audio
Only audio addressed to your device passes to your ASR. Everything else is suppressed first.
When SAA is uncertain it fails closed and forwards nothing.
License per device, across every category
SAA is licensed per device, negotiated per program across every category you ship into.
No BOM impact. A DPA is available for regulated deployments.
Why the existing stack does not solve it
None of the existing layers decide who your device is being addressed by.
The table below breaks down what each layer answers, when it runs, and whether it decides who is addressed.
| Layer | What it answers | When it runs | Decides who is addressed? |
|---|---|---|---|
| Voice activity detection (VAD) | Is someone speaking? | Pre-ASR | No |
| Beamforming and direction-of-arrival | Where is the speaker located? | Pre-ASR | No |
| Speaker diarization | Who spoke, and when? | Post-ASR | No |
| Wake word | Was a trigger phrase said? | Pre-ASR | Phrase only |
| Speaker identification | Is this a known registered voice? | Post-ASR | No |
| SAA addressee detection | Is the device being addressed, right now? | Pre-ASR, real time | Yes |
Voice activity detection (VAD)
AnswersIs someone speaking?
WhenPre-ASR
Addressed?No
Beamforming and direction-of-arrival
AnswersWhere is the speaker located?
WhenPre-ASR
Addressed?No
Speaker diarization
AnswersWho spoke, and when?
WhenPost-ASR
Addressed?No
Wake word
AnswersWas a trigger phrase said?
WhenPre-ASR
Addressed?Phrase only
Speaker identification
AnswersIs this a known registered voice?
WhenPost-ASR
Addressed?No
SAA addressee detection
AnswersIs the device being addressed, right now?
WhenPre-ASR, real time
Addressed?Yes
For OEM and hardware teams that need addressee detection as a licensable per-device IP block.
Common questions
What OEM and hardware teams ask before integrating.
Does SAA force us to change our ASR vendor, voice model, or microphone hardware?
No. SAA is a neutral, pre-ASR layer. It makes one decision, whether an utterance is addressed to your device, and routes only addressed audio to your ASR.
Your ASR, voice model, microphone, and hardware are unchanged. SAA is model- and device-agnostic, and works in front of any pipeline you already run.
Is SAA hosted or does it run on the device?
SAA is a hosted cloud service on GCP. Your device streams audio to server.attentionlabs.ai via thin client SDKs in JavaScript/TypeScript and Python.
The routing decision returns in real time, before speech-to-text, and fails closed when uncertain. A DPA is available for regulated deployments.
What decision latency does SAA add to our pipeline?
The routing decision returns in real time, before ASR begins processing. It sits where a normal pre-ASR stage already runs in most voice pipelines.
SAA requires no GPU and no wake word. Non-addressed audio is suppressed before it reaches ASR, which reduces unnecessary compute downstream.
How is SAA different from VAD, beamforming, or a wake word?
VAD detects that speech is present. Beamforming and direction-of-arrival localize the source. A wake word fires on a fixed trigger phrase. None of these answer whether the utterance was addressed to your device.
SAA adds exactly that decision, in real time, before ASR runs, with no required trigger phrase and no GPU.
Does SAA require a microphone array or additional hardware?
No array and no GPU are required. SAA runs on the microphone your device already ships with, and the client SDK streams audio to the hosted service.
There is no BOM impact and no hardware redesign.
How do we evaluate SAA on audio from our own device and environment?
The evaluation tier is free.
Request an eval and the team provides API keys, an eval kit, and the client SDK so you can test SAA on your own device audio.
How is SAA licensed for OEM and hardware programs?
SAA is licensed per device. Licensing terms are arranged directly for each program across device categories.
Request an eval to start the technical evaluation, or book a call to discuss integration scope and commercial terms.
Get in touch
Book a call or run a free eval on your own device audio.
Tell us about your device and deployment environment. We will scope a free evaluation using your own audio.
Or try the Cloud SDK to get a feel.
Last updated June 27, 2026