Skip to main content

Limits

The bounds a session runs under, and what happens when one is reached.

Audio format #

Audio is 16 kHz, mono, signed 16-bit little-endian PCM. The protocol_version is "1.0".

Session bounds #

  • Audio per session — at most 3600 seconds.
  • Audio per message — at most 2 seconds.
  • Audio waiting on the server — at most 8 seconds; beyond that the server pushes back.
  • Enrollment audio for ts_asr — 12 seconds. Send all 12: a shorter clip costs more to set up, not less.
  • Idle time — a session with no audio for 30 seconds is ended.

These are the defaults; a deployment may set different values. The server also holds at most 128 undelivered events per session, so a client that stops reading is cancelled as Errors describes.

Request fields #

  • expected_num_speakers is "auto" or an integer from 1 to 8 on HEAT4, the engine served, which transcribes at most four speakers at once; from 1 to 4 on the dicon engine. There is no higher count.
  • Speech is transcribed in English only; there is no language field, and speech in another language is not supported.
  • client_request_id is optional, 1 to 128 characters, matching ^[A-Za-z0-9._:-]+$.

Quotas #

A key may carry a quota in audio seconds. A key with no quota set is unlimited, not zero. Consumption counts audio the service processed, not audio submitted, and is recorded when a session ends.

The quota is checked twice. A new session is refused at admission when the key's recorded consumption already meets it. A running session's processed audio is measured against it as it streams: on crossing the quota the service sends one quota.warning with quota_audio_seconds, consumed_audio_seconds and grace_audio_seconds, and the session continues to a grace threshold of 1.25 times the quota, a chosen policy value. It is then cancelled with reason quota exhausted.

A key with a quota has one live session at a time on a worker host. A second new session while the first is live is refused with overload before any audio is accepted, and the key can start another once the first ends. Without this, concurrent sessions would all spend the same recorded balance.

Attaching to an existing session on /v1/sessions/{session_id}/stream is not quota-checked, because the session was admitted already; that session runs until its own bounds end it.

A new session over quota gets quota_exhausted, which is not retryable. A session refused for capacity gets overload, which is. Errors lists every code.