Your Dictation Feature Doesn't Need a WebSocket

This story was originally published on HackerNoon at: https://hackernoon.com/your-dictation-feature-doesnt-need-a-websocket. Push-to-talk audio is already recorded, so it doesn't need a WebSocket. Transcribe short clips in one HTTP request, and see where the latency hides. Check more stories related to undefined at: https://hackernoon.com/c/undefined. You can also check exclusive content about #speech-to-text, #voice-dictation, #synchronous-transcription, #assemblyai-sync-api, #push-to-talk-transcription, #websocket-transcription, #http-audio-transcription, #good-company, and more. This story was written by: @assemblyai. Learn more about this writer by checking @assemblyai's about page, and for more stories, please visit hackernoon.com. Most "real-time" voice features aren't streaming problems. If the user held a button, spoke, and let go, the audio was finished before you sent the first packet — that's a request and a response, not a session. A sync speech-to-text endpoint takes a complete clip and returns a complete transcript in one HTTP call, with no job ID, no polling, and no end-of-turn logic to tune. The non-obvious part is latency. On a single-request API there's no session to amortize connection setup against, so every cold request pays DNS, TCP, and TLS before a byte of audio moves — which can cost more than the ~134 ms transcription itself for an intercontinental client. Calling /warm the instant the user presses the button runs that handshake concurrently with the recording and takes it off the critical path entirely. The tradeoff: the sync path is deliberately narrow. Audio caps at 120 seconds and 40 MB, WAV or raw PCM only, and there's no diarization or PII redaction. For anything longer or still arriving, use async or streaming.