Skip to main content
Identify and label individual speakers in real time, or transcribe multichannel audio using the Streaming API.

Overview

Streaming Diarization lets you identify and label individual speakers in real time directly from the Streaming API. Each Turn event includes a speaker_label field (e.g. A, B) indicating the dominant speaker for that turn. Each final word in the words array also carries a speaker field, enabling mid-turn speaker change detection. Speaker accuracy improves over the course of a session as the model accumulates embedding context — so the longer the conversation, the better the labels.
Already using AssemblyAI streaming?You can enable Streaming Diarization by adding speaker_labels: true to your connection parameters. No other changes are required — the speaker_label field will appear on every Turn event, and each final word in the words array will include a speaker field automatically.

Quickstart

Enable Streaming Diarization by setting speaker_labels to true when you open the WebSocket.

Configuration

Enable Streaming Diarization by adding speaker_labels: true to your connection parameters. You can optionally cap the number of speakers with max_speakers. This is a hard limit, not a hint: if more people speak than the value you set, the additional speakers are merged into the closest existing speaker label rather than given a new one. If you’re unsure of the exact speaker count, set max_speakers a little higher than what you expect so the model has room to identify any additional speakers. Setting it too high, though, can cause the model to over-split — assigning new speaker labels to segments that actually belong to an existing speaker.
Diarization is supported on all streaming models: universal-3-5-pro, universal-streaming-english, and universal-streaming-multilingual. You do not need to change your speech model to use it — just add speaker_labels: true.

Reading speaker labels

When diarization is enabled, every Turn event includes a speaker_label field reflecting the dominant speaker for that turn.

Word-level speaker labels

Each final word in the words array also carries a speaker field. This allows you to detect speaker changes within a single turn — for example, a turn where one speaker finishes another’s sentence, or where a brief interjection appears mid-turn.
A few things to keep in mind when consuming speaker:
  • Final words only. The speaker field only appears on words where word_is_final: true. Non-final (in-progress) words never carry it.
  • speaker can be absent on individual words. If the field is missing from a word entirely, treat that word as unattributed and fall back to the turn-level speaker_label if you need a label. Absent means the field is omitted from the JSON — it will never be null.
  • UNKNOWN at word level means the model couldn’t confidently attribute that word to any specific speaker — common for short backchannels (“uh huh”, “yeah”) or brief low-quality audio segments. It is not an ambiguity flag between two known speakers; words in a confidently-attributed stretch carry the speaker’s letter, not UNKNOWN.
If a turn contains less than approximately 1 second of audio, the turn-level speaker_label will be set to "UNKNOWN". This is because the model needs at least ~1 second of audio to generate a reliable diarization embedding — without enough audio, embeddings may be inaccurate and could lead to a single speaker being labeled as multiple speakers. Labeling short turns as "UNKNOWN" ensures that speaker labels remain as accurate as possible.
Your application should handle this case gracefully. A typical multi-speaker exchange looks like this:

How speaker accuracy improves over time

Streaming Diarization builds a speaker profile incrementally as audio flows in. In practice this means:
  • Early in a session, speaker assignments may be less stable, especially if the first few turns are short.
  • As the session progresses, the model accumulates richer speaker embeddings and assignments become more consistent.
For long-form use cases (call center, clinical scribe, meeting transcription), the model will settle into accurate, stable labels well before the end of the conversation.

Revised speaker labels

During a live session, Streaming Diarization assigns speaker_label values in real time as each Turn is emitted. These labels can shift as the session progresses and more audio becomes available. Early turns in particular may be reassigned as the model builds a clearer picture of each speaker. When the session ends, the server performs a final refinement pass with full visibility into the entire conversation. Any turns whose speaker labels changed are sent back as a single SpeakerRevision message. Turns that were already correct are omitted. Use the revised labels whenever you need the highest-quality speaker attribution for the final transcript — for example, when persisting a meeting transcript, generating a post-call summary, or feeding text into a downstream LLM that benefits from accurate speaker turns.
The end-of-session refinement adds approximately 400ms of latency. Any SpeakerRevision messages arrive before the Termination message and do not affect the real-time speaker_label values delivered during the session.

Message shape

A single SpeakerRevision message is sent at the end of the session containing a revisions array. Each item corrects one turn; only turns whose speaker assignments changed are included. The turn_order field in each item matches the turn_order of the original Turn message being revised.
Text content and word timestamps are never changed. Only speaker assignments are revised.

How to handle it

Match each turn_order in revisions against the turn you already received, then replace its speaker_label and per-word speaker values.

When it is sent

SpeakerRevision messages are only sent at the end of a stream, after the Terminate signal. They are never emitted mid-session. A given session may produce zero or many revisions. Only turns whose speaker assignments changed are included. If the session ends unexpectedly (network drop, error closure), revisions may not be delivered. Always handle this gracefully and fall back to the live labels you received during the session.

Known limitations

Real-time diarization is an inherently harder problem than diarization for async transcription on pre-recorded audio. The following limitations apply to the current beta:
  • Short utterances — Turns with less than ~1 second of audio are labeled as "UNKNOWN" because there is insufficient audio to generate a reliable speaker embedding. This prevents inaccurate embeddings from causing a single speaker to be split across multiple labels.
  • Overlapping speech — When two speakers talk simultaneously, the model cannot split the audio and will assign the turn to a single speaker. Performance degrades with frequent cross-talk.
  • Session start accuracy — The first 1–2 turns of a session may be misassigned because the model has not yet built up speaker profiles. This self-corrects quickly in practice.
  • Noisy environments — Background noise and microphone bleed between speakers can reduce embedding quality and lead to more frequent misassignments.
For the best results, use a microphone setup that minimizes cross-talk and background noise, and ensure each speaker produces at least a few complete sentences before you rely on per-turn labels for downstream processing.

Multichannel streaming audio

To transcribe multichannel streaming audio, we recommend creating a separate session for each channel. This approach allows you to maintain clear speaker separation and get accurate diarized transcriptions for conversations, phone calls, or interviews where speakers are recorded on two different channels. The following code example demonstrates how to transcribe a dual-channel audio file with diarized, speaker-separated transcripts. This same approach can be applied to any multi-channel audio stream, including those with more than two channels.
1
Firstly, install the required dependencies.
2
Use this complete script to transcribe dual-channel audio with speaker separation:
Configure turn detection for your use caseThe examples above use turn detection settings optimized for short responses and rapid back-and-forth conversations. To optimize for your specific audio scenario, you can adjust the turn detection parameters.For configuration examples tailored to different use cases, refer to our Configuration examples.
Modify the turn detection parameters in API_PARAMS: