Per-participant audio gives you a separate audio track for each person in a meeting.
You do not get one mixed recording of everyone. Each voice sits on its own channel.
That makes transcription, speaker attribution and voice analysis far more accurate, above all when people talk over each other.
How per-participant capture works
In a video conference, each person's microphone already makes its own stream. The platform mixes them for playback.
Per-participant capture taps those streams before the mix, or instead of it.
A meeting bot in the call subscribes to each person's audio on its own.
You get the tracks as live streams, or as separate files after the meeting. The result is a set of clean tracks.
Each track carries the audio and the identity of the person who spoke.
The specifics: per-participant files are WebM/Opus at 48 kHz mono. You can get up to 16 speaker streams at once.
You fetch them through presigned URLs that expire after ten minutes.
A person's file holds the meeting audio from the times they were the active speaker.
That is exact for normal turn-taking, and only approximate under cross-talk. The live WebSocket stream is mixed audio.
The Zoom page and the RTMS entry explain why Zoom is the exception.
The Recall migration case study is the workload it decided.
Why separate tracks beat a mixed recording
Separate tracks keep detail that a single mixed recording blends away:
- Speaker attribution is exact, since each track maps to a known person
- Speech that overlaps stays clear, since two voices never share a channel
- Transcription improves, as engines process one clean voice at a time
- You can level volume and quality for each person
- Sentiment or talk time runs per speaker, with no diarization errors
What teams use separate tracks for
Conversation intelligence tools need separate tracks. That is how they measure talk ratios and interruptions.
Interview and user research tools need to know who asked and who answered. Podcast-style editors remix single tracks.
Voice AI teams use clean speech as training or test data. Real-time agents use it to know who is talking to them.
What to plan for
Not every capture method offers it. Built-in platform recordings give you just a mixed track.
So per-participant audio usually needs a bot to capture it through an API.
Expect one stream or file per attendee, so storage and processing grow with the head count. Plan for edge cases too.
When several people share one meeting room microphone, diarization within a track still helps.
Per-participant audio in practice
MeetStream bots give you a separate WebM audio file per participant after the call.
You also get a live mixed stream over WebSocket in roughly 200 ms, tagged with the speaker.
And you get MP4 recordings and speaker-identified transcripts.
One API call with the meeting link starts capture on Zoom, Google Meet, or Microsoft Teams.
The MeetStream docs describe the stream format. See the meeting bot API page to go deeper.
Frequently asked questions
Does per-participant audio remove the need for diarization?
Largely, yes. Each track already belongs to a known person, so attribution is direct. It does not rely on voice clustering.
Diarization still helps inside a single track, when several people share one device in a meeting room.
Can I get per-participant audio from a normal cloud recording?
Usually not. Built-in platform recordings give you one mixed track. For separate tracks you need a bot in the meeting.
It subscribes to each person's stream on its own.
Is per-participant audio available live or only after the call?
Both, depending on the provider. Live separate streams feed real-time transcription and agents. Separate post-call files suit editing and analysis work.
Some APIs offer the two together from the same bot.
Put the vocabulary to work
One API to join, record, stream, and transcribe meetings on Zoom, Google Meet, and Microsoft Teams.