Audio Formats

All speech-to-text endpoints accept audio in two ways: a container format that the server detects automatically, or raw audio described explicitly with the encoding, sample_rate, and channels query parameters.

Automatic Detection

With the default encoding=auto, the server detects the audio format by reading the container headers at the start of the data. Most common formats (WAV, M4A, MP3, OGG, FLAC, WebM, etc.) are supported.

On the Prerecorded endpoint, you can also set a seekable media container explicitly: m4a, m4v, mp4, mov, 3gp, or 3g2.

Raw Audio

If you are sending raw audio without container headers, set the encoding parameter explicitly along with sample_rate and channels:

Encoding	Description
pcm_s16le	Raw PCM, 16-bit little-endian
mulaw	G.711 mu-law telephony audio
alaw	G.711 A-law telephony audio

Streaming Containers

When streaming to the Realtime or Turns endpoint, you can use a container with an indefinite length (e.g. a WAV header with the data size set to the maximum value) and continuously append audio frames.

Recommended streaming setup

If you control the capture pipeline, send raw PCM at 16 kHz mono: encoding=pcm_s16le&sample_rate=16000&channels=1. There are no container headers to lose, so the reconnecting caveat below does not apply.

Reconnecting mid-stream

If you reconnect to the WebSocket and resume sending audio, the server will not be able to detect the format because the container headers are missing. Each new connection must start with a fresh audio stream that includes the headers. Alternatively, set the encoding parameter explicitly to bypass format detection entirely.

Chunk Size

When streaming to the Realtime or Turns endpoints, the size of each binary WebSocket message is up to you. The server buffers incoming audio internally, so chunks don’t need to line up with sample or frame boundaries, and the size can vary between messages.

As a guideline, send 20 to 100 ms of audio per message as you capture it:

• Smaller chunks add per-message overhead without lowering latency.
• Larger chunks delay transcripts, because the server can’t process audio it hasn’t received yet.

For raw audio, the size of a chunk follows from the format. For example, 100 ms of pcm_s16le at 16 kHz mono is 3,200 bytes (16,000 samples/s × 2 bytes × 0.1 s).

Each message must be at most 64 KiB. Larger messages are rejected and the connection is closed. When streaming from a file instead of a live source, read it in chunks of a few KiB rather than sending it in one message.