In-cabin voice arbitration for Tier-1 IVI and automotive OEM
The IVI fires on the passenger.
The failure
Seat-aware routing tells you where the audio came from. It does not tell you who to obey.
The driver corrects it. That is the product failing.
Driver says "play jazz." Passenger says "no, podcasts" at the same instant. A back-seat child trips the wake word.
The mic array hears all three, with no way to pick a winner.
Beamforming assigns zones. Seat-aware routing sends each stream to a path.
Neither decides who addressed the device, so the assistant acts on whichever signal arrives first or loudest.
Cockpit assistants are taking on agentic control of navigation, climate, and connectivity.
Acting on the wrong occupant is no longer just a UX glitch. It is a safety and brand problem.
false activation
The assistant acts on the wrong occupant
The driver's intent is ignored. In an agentic cockpit, the wrong action executes on navigation, controls, or connectivity.
brand quality and safety
The correction interaction is the product failing
False activations are among the most cited drivers of negative in-cabin voice ratings, tracked at program level by OEM product teams.
The correct response to an unaddressed utterance is silence.
The fix
One hosted layer that decides who to answer, before the IVI acts.
SAA runs as a single hosted checkpoint between the cabin mic-array DSP and the assistant NLU.
It decides, before speech-to-text, which occupant is addressing the device, and arbitrates when more than one speaks at once.
Only device-directed audio from the correct principal reaches your ASR and NLU. Everything else is suppressed before transcription begins.
No wake word. No GPU on vehicle hardware. Fails closed under uncertainty. Licensed per device as a drop-in IP block above your existing stack.
Research foundation
Built on our published technical paper.
SAA reliably determines whether speech is device-directed, on audio alone or with audio-and-video fusion.
Validated on held-out multi-party sessions (arXiv:2604.08412).
Two caveats apply to both modes: the system fails closed under distribution shift, and cross-lingual recall is a known limitation under active work.
performance
Reliable on audio and video fusion
Validated on held-out multi-party sessions with multiple concurrent speakers, as a fully occupied cabin produces (arXiv:2604.08412).
performance
Reliable on audio-only
Real multi-speaker audio, no video stream required.
latency
Real-time decision, before STT
The addressee decision returns before your ASR begins, with no GPU required on vehicle hardware and no perceptible delay to the interaction.
design principle
Fails closed by design
Ambiguous utterances are suppressed, not passed through. The default state under uncertainty is silence, not a wrong action.
coverage
Up to 4 simultaneous speakers
The multi-occupant load a fully loaded cabin actually produces.
signal model
Runs on audio, not language
The decision uses the raw audio signal before ASR, with no per-language model required, which is why cross-lingual recall remains active work.
How it integrates
Where SAA sits in your Tier-1 IVI voice stack.
SAA inserts between the cabin mic-array DSP and the assistant NLU. Your DSP, ASR vendor, and NLU remain unchanged.
Stream cabin audio after DSP
Processed audio frames from your mic array, after echo cancellation and beamforming, stream to the SAA hosted service.
Use the client SDK in JavaScript/TypeScript or Python.
Optional video from cabin-facing cameras can be added for richer addressee context (arXiv:2604.08412).
Addressee and arbitration decision
SAA classifies each frame as device-directed, human-directed, or ambient across multiple concurrent speakers.
When multiple occupants speak simultaneously, SAA applies a configurable arbitration policy. Decision returned in real time, before STT.
Route only addressed audio to ASR and NLU
Human-directed speech between occupants, ambient audio, and accidental wake words are suppressed before transcription begins.
Uncertain frames fail closed and are not forwarded.
Drop-in for existing Tier-1 stacks
SAA is model-agnostic.
It works with whichever ASR and NLU stack the Tier-1 or OEM is already running, on existing cockpit compute, with no hardware changes.
The service runs as a hosted GCP deployment and is licensed per device.
architecture
Hosted, pre-ASR, behind any model
JavaScript/TypeScript and Python SDKs stream cabin audio to server.attentionlabs.ai, behind whichever ASR and NLU stack you already run.
access
Eval is free. Licensing is per device.
Book a call to scope a deployment, or request a free evaluation against your own cabin audio.
Book a callWhy existing layers miss it
Beamforming, VAD, and wake words do not decide who the assistant should answer.
Every cabin audio stack already does signal processing.
Beamforming isolates the speaker spatially, wake words catch a trigger phrase, VAD detects that someone is speaking.
None of them answers the addressee question: which occupant is speaking to the device, and who wins when two speak at once?
That decision has to happen before ASR, or every utterance reaches the part of the pipeline that acts on it.
| Layer | What it answers | When it runs | Decides who is addressed? |
|---|---|---|---|
| Beamforming / AEC | Where is the dominant speaker located? | Pre-ASR | No |
| Seat-aware routing | Which zone did the audio come from? | Pre-ASR | No |
| Voice activity detection (VAD) | Is someone speaking? | Pre-ASR | No |
| Wake word | Was the trigger phrase spoken? | Pre-ASR | Phrase only; no arbitration |
| Speaker diarization | Who spoke, and when? | Post-ASR | No |
| SAA addressee detection | Is the device being addressed, by which principal, right now? | Pre-ASR, in real time | Yes, with arbitration policy |
regulatory context
NHTSA distraction guidelines
NHTSA guidance flags secondary task demand as a driver distraction risk factor.
An in-cabin assistant that activates on unaddressed speech interrupts the driver at the exact moment their attention is safety-critical.
SAA prevents the assistant from activating on non-directed speech.
regulatory context
ASIL, AUTOSAR, and MISRA posture
SAA is a hosted perception module, not a safety-critical ECU. It sits upstream of NLU as a routing filter, outside the functional safety path.
Tier-1 and OEM integration teams determine the final system architecture and safety analysis.
A DPA is available for regulated deployments. Book a call to discuss your constraints with the engineering team.
Fewer false activations. A licensable, per-device IP block.
Common questions
What Tier-1 and OEM integration teams ask before scoping.
What is SAA and what does it do for in-cabin voice assistants?
SAA (Selective Auditory Attention) is a hosted, pre-ASR engagement-control layer.
It decides, before speech-to-text, which cabin occupant is addressing the device, using audio alone or audio-and-video fusion (arXiv:2604.08412).
Only addressed audio reaches your ASR and NLU; everything else is suppressed before transcription.
No wake word, no GPU on vehicle hardware, fails closed when uncertain.
Why do in-cabin voice assistants false-activate on the wrong occupant?
A vehicle cabin is a real many-to-many room.
When the driver and front passenger speak at once, or a child in back trips the wake word, the assistant has no way to decide whose speech to act on.
Beamforming and seat-aware routing separate audio spatially. Neither arbitrates between occupants or decides who the device was addressed by.
SAA adds that decision before ASR runs, and fails closed when uncertain.
How is SAA different from seat-aware routing or beamforming?
Beamforming answers where the dominant speaker is physically located. Seat-aware routing sends audio from different zones to different processing paths.
Neither decides whether a speaker is addressing the assistant or another occupant, or arbitrates when two occupants speak at once.
SAA adds that decision above spatial processing, using a configurable policy to pick which occupant's intent to act on.
Where does SAA sit in a Tier-1 IVI voice stack?
SAA sits between the mic-array DSP output and the assistant NLU.
Audio from the cabin mic array, after echo cancellation and beamforming, streams to the hosted service at server.attentionlabs.ai.
SAA returns an addressee decision in real time, before speech-to-text, so only device-directed audio reaches your ASR and NLU.
It is model-agnostic and works with whichever stack the Tier-1 or OEM already runs. SDKs are available in JavaScript/TypeScript and Python.
What about ASIL, AUTOSAR, and MISRA compliance, and what is the latency budget?
SAA is a hosted perception module, not a safety-critical ECU. It sits upstream of NLU as a routing filter, outside the functional safety path.
Your integration team owns the final system architecture and safety analysis.
The addressee decision returns before speech-to-text, inside the latency budget of a voice interaction, leaving your ASR and NLU pipeline intact.
A DPA is available. Book a call to discuss ASIL, AUTOSAR, and MISRA constraints.
How does SAA handle two occupants speaking at the same time?
SAA classifies each utterance as device-directed, human-directed, or ambient.
When two occupants speak at once, a configurable arbitration policy, for example driver-primary, decides whose intent to act on.
Ambiguous or uncertain utterances are suppressed by default: the system fails closed, and uncertain frames are never forwarded to ASR.
What does the evaluation path look like?
The evaluation tier is free. Request an eval and we provide API keys, a client SDK, and an eval kit to run SAA against your own cabin audio.
The typical path is an architecture call, a free cloud evaluation against your cabin audio, then a structured multi-quarter paid POC against agreed thresholds.
Licensing after a successful POC is per device.
Get in touch
Book a call or request an eval.
Tier-1 cockpit suppliers and OEM IVI product leads: describe your voice stack, mic zone count, and where addressee arbitration is breaking down.
We will schedule an architecture call, scope a free cloud evaluation against your cabin audio, and discuss DPA requirements ahead of a paid POC.
Want to explore first? Try the Cloud SDK to get a feel for it.
Learn more
What is addressee detection Addressee detection vs VAD Technology and integration
Or email us directly: [email protected]
Last updated June 27, 2026