Getting started
Get started with Gladia Real-time Speech to Text (STT) API
Initiate your real-time session
First, call the endpoint and pass your configuration.
It’s important to correctly define the properties encoding
, sample_rate
, bit_depth
and channels
as we need them to parse your audio chunks.
You’ll receive a response with a WebSocket URL to connect to. If you loose connection, you can reconnect to that same URL and resume where you left off. Here’s an example of a response:
Connect to the WebSocket
Now that you’ve initiated the session and have the URL, you can connect to the WebSocket using your preferred language/framework. Here’s an example in JavaScript:
Send audio chunks
You can now start sending us your audio chunks through the WebSocket. You can send them directly as binary, or in JSON by encoding your chunk in base64, like this:
Read messages
During the whole session, we will send various messages through the WebSocket, the callback URL or webhooks. You can specify which kind of messages you want to receive in the initial configuration. See messages_config
for WebSocket messages and callback_config
for callback messages.
Here’s an example of how to read a transcript
message received through a WebSocket:
Sending multiple audio tracks in real-time
If you have multiple audio sources (like different participants in a conversation) that you need to transcribe simultaneously, you can merge these separate audio tracks into a single multi-channel audio stream and send it over one WebSocket connection.
Merging multiple audio tracks into one multi-channel WebSocket
This approach allows you to consolidate multiple audio tracks from different participants into a single WebSocket connection while maintaining the ability to identify each speaker through their dedicated channel.
Benefits:
- Reduce the number of WebSocket connections from multiple to just one
- Maintain speaker identity through channel mapping
- Simplify synchronization of audio streams from multiple participants
- Reduce network overhead and connection management complexity
Creating a multi-channel audio stream
To combine multiple audio tracks into a single multi-channel stream, you need to interleave the audio samples. Here’s a TypeScript function that merges multiple audio buffers into a single multi-channel buffer:
Example use case
Consider a scenario with three participants in a room: Sami, Maxime, and Mark. Instead of opening three separate WebSocket connections (one for each participant), you can merge their audio tracks and send them over a single WebSocket:
- Collect audio buffers from each participant
- Merge them into a single multi-channel audio stream using the
interleaveAudio
function - Specify the number of channels in your API configuration (3 in this case)
- Send the combined audio over a single WebSocket
Understanding the response
When you send a multi-channel audio stream to Gladia, the channel order is preserved in the transcription results. Each transcription message will include a channel
field that indicates which audio channel (and thus which participant) the transcription belongs to:
The channel numbers directly correspond to the order in which you added the audio tracks to the channelsData
array:
- Channel 0 → Sami (first in the array)
- Channel 1 → Maxime (second in the array)
- Channel 2 → Mark (third in the array)
Remember to keep track of channel assignments in your application to properly attribute transcriptions to the correct participants.
As mentioned in the Multiple channels section, transcribing a multi-channel audio stream will be billed based on the total duration multiplied by the number of channels.
Read messages
During the whole session, we will send various messages through the WebSocket, the callback URL or webhooks. You can specify which kind of messages you want to receive in the initial configuration. See for WebSocket messages and for callback messages.
Here’s an example of how to read a message received through a WebSocket:
Stop the recording
Once you’re done, send us the stop_recording
message. We will process remaining audio chunks and start the post-processing phase, in which we put together the final audio file and results with the add-ons you requested.
You’ll receive a message at every step of the process in the WebSocket, or in the callback if configured. Once the post-processing is done, the WebSocket is closed with a code 1000.
Instead of sending the stop_recording
message, you can also close the WebSocket with the code 1000.
We will still do the post-processing in background and send you the messages through the callback you defined.
Get the final results
If you want to get the complete result, you can call the GET /v2/live/:id
endpoint with the id
you received from the initial request.
Full sample
You can find a complete sample in our Github repository:
Was this page helpful?