Tal till text i realtid under 200 ms: en arkitekturguide

Tal till text i realtid (STT) transkriberar ljud medan någon pratar och visar texten inom några hundra millisekunder. Men att hålla STT-fördröjningen låg handlar lika mycket om arkitektur som om modellval. Utvecklare behöver planera för transport, uppdelning, end-pointing och inspelning – varje steg lägger till fördröjning. Om något av dessa är ineffektivt spräcker du snabbt din 200 ms-budget.

Den här guiden ger dig ett praktiskt system för att bygga tal till text-pipelines i realtid, från transportlagret och uppåt. Vi utgår från Scribe v2 Realtime, som ger deltranskriptioner på cirka 150 ms modellfördröjning, stödjer 90+ språk, tar emot PCM (8kHz-48kHz) och mu-law-ljud, och har Voice Activity Detection samt manuell commit-kontroll för segmentavslut.

Vi går igenom hur ljudet når servern, hur hypoteser blir till bekräftad text, vad in-stream-funktioner kostar och hur du fångar och skickar ljud på rätt sätt.

Sammanfattning

• Att skapa tal till text-system i realtid kräver att du finjusterar arkitekturen så att fördröjningen hålls låg genom hela kedjan.
• WebSocket är oftast rätt val för de flesta pipelines, även om WebRTC har sina fördelar men är mer komplext.
• Voice Activity Detection hanterar handsfree-segmentering, medan manuell commit låter din app ta över när den vet att det är användarens tur att sluta prata.
• Deltranskriptioner är provisoriska och slutgiltiga är bekräftade – visa dem olika.
• Små PCM-bitar på runt 100 ms minimerar fördröjningen till första deltranskriptionen.

WebSocket vs. WebRTC för tal till text i realtid

Innan någon transkribering sker måste ljudet ta sig från källan till igenkännaren. Kanalen du väljer sätter lägstanivån för fördröjning i hela kedjan. Det finns två realistiska alternativ för att få ljudet till transkriptionslagret.

WebSocket är en långlivad, ordnad, pålitlig, tvåvägskanal över TCP. Du öppnar en anslutning, skickar binära ljudramar upp och tar emot transkriptioner ner. Det är enkelt både på klient och server, fungerar genom de flesta företagsproxies och brandväggar som redan släpper igenom HTTPS, och stöds av alla webbläsare och servermiljöer.

Begränsningen med WebSocket är att det körs över TCP. Om ett paket tappas skickar TCP om det och håller tillbaka senare data tills luckan är fylld. Vid bra nätverk märks det inte, men vid paketförlust kan det bli en kort paus där ljudet samlas upp och sedan kommer i en klump.

WebRTC är byggt för media i realtid. Det kör media över UDP (via SRTP), så ett tappat paket stoppar inte strömmen – pipeline fortsätter. Det har en jitterbuffert som jämnar ut variationer i paketleverans, förhandlar NAT-traversering med ICE/STUN/TURN så att klienter bakom routrar kan ansluta, och har egen ljudinspelning och kodning.

Du behöver ofta TURN-servrar för klienter som inte kan ansluta direkt, och serversidan måste avsluta en mediaström istället för att läsa en bytestream.

Här är jämförelsen i korthet:

För de flesta användningsområden är WebSocket rätt val. Använd det när dina klienter har bra uppkoppling och du kontrollerar inspelningen: server-till-server-pipelines, desktopappar, webbläsarappar på bredband och de flesta kontaktcenter där ljudet redan når din server på annat sätt.

Välj WebRTC när du spelar in direkt från konsumentenheter på opålitliga mobilnät, när du redan kör WebRTC för tvåvägsljud (till exempel en röstagent som även svarar), eller när låg förlust och realtidsbeteende är viktigare än enkel implementation.

Resten av guiden utgår från WebSocket-transport till igenkännaren, eftersom det gör flödet tydligt och är en bra startpunkt för de flesta team. Inget är dock WebSocket-specifikt – du kan senare lägga till en WebRTC-del före, avkoda ljudet till PCM på servern och skicka samma bitar vidare i pipeline.

Deltranskriptioner och slutgiltiga transkriptioner: så funkar det

En igenkännare i realtid väntar inte på en hel mening innan den svarar. Istället skickar den en ström av gissningar som blir tydligare ju mer ljud som kommer, och låser sedan in dem. Att förstå skillnaden mellan dessa två lägen är det som gör att en transkription känns levande istället för trasig.

En deltranskription (interim) är modellens bästa gissning utifrån det ljud som kommit in hittills. Deltranskriptioner är instabila med flit. När mer ljud kommer kan modellen ändra tidigare ord: "Jag vill" kan bli "Jag vill ha två biljetter" när mer kontext kommer. De kommer snabbt (det är detta ~150 ms syftar på) och ska skrivas över.

En slutgiltig transkription är ett bekräftat segment som inte ändras. När ett segment är klart går igenkännaren vidare och nya hypoteser gäller senare ljud. Slutgiltiga transkriptioner är de du sparar, skickar till en LLM eller lagrar som transkript.

Skillnaden mellan deltranskriptioner och slutgiltiga påverkar tre saker som ofta blir fel om du blandar ihop dem:

• Användarupplevelse: Att visa deltranskriptioner gör att transkriptionen känns levande: användaren ser orden dyka upp medan de pratar, vilket bekräftar att mikrofonen fungerar och systemet lyssnar.
• End-pointing: Deltranskriptioner ger en kontinuerlig signal om talaktivitet. Tillsammans med VAD kan du avgöra när talaren faktiskt har slutat.
• Timing nedströms: I en voice agent-pipeline är stegen: ljud in, sedan tal till text, sedan en LLM, sedan text till tal, sedan ljud ut. Du kan börja spekulativt arbete på deltranskriptioner och bekräfta på slutgiltiga, vilket minskar upplevd svarstid men ibland innebär att spekulativt arbete kastas.

Visa deltranskriptioner och slutgiltiga olika. Ett enkelt och effektivt mönster är att ha en "aktuell rad" som uppdateras med senaste deltranskriptionen och läggs till i transkriptet när en slutgiltig kommer:

type TranscriptState = {
  committed: string[]; // finalized segments, never rewritten
  current: string;     // latest partial, overwritten on each update
};

const onPartial = (s: TranscriptState, text: string): TranscriptState =>
  ({ ...s, current: text });

const onFinal = (s: TranscriptState, text: string): TranscriptState =>
  ({ committed: [...s.committed, text], current: "" });

Visa bekräftad text som fast och aktuell text i ljusare eller kursiv stil så användaren förstår att den kan ändras.

End-pointing och Voice Activity Detection (VAD)

Att veta vad som sagts är bara halva jobbet. En igenkännare måste också veta när en tanke är slut. Det styr när du avslutar ett segment och, för en agent, när systemet börjar svara.

End-pointing är beslutet att ett yttrande är slut. Om du avslutar för tidigt avbryts användaren mitt i meningen. Om du avslutar för sent blir agenten tyst efter att användaren är klar.

Scribe v2 Realtime ger dig två kompletterande verktyg:

• Voice Activity Detection delar upp ljudet baserat på tystnad: Igenkännaren märker när tal övergår i tystnad och använder den gränsen för att automatiskt avsluta ett segment. VAD är rätt standard för konversationsgränssnitt eftersom det anpassar sig till naturligt taltempo utan att du behöver hålla koll på tiden själv.
• Manuell commit-kontroll: Manuell commit-kontroll låter din app bestämma när det är dags att avsluta nuvarande segment, oberoende av tystnad. Du skickar en commit-signal, igenkännaren stänger segmentet och skickar en slutgiltig. Det är rätt verktyg när din app redan vet att det är användarens tur: när en push-to-talk-knapp släpps, en "skicka"-åtgärd eller en extern turpolicy.

De två fungerar bra ihop. En typisk röstagent använder VAD för handsfree och erbjuder manuell commit som överskrivning, så att en användare som pausar inte avbryts men en som trycker på en knapp får omedelbar avslutning.

Tystnadströskeln är en verklig avvägning utan universellt rätt värde:

• En kort timeout för slut på tal (t.ex. avslut efter ~200-400 ms tystnad) gör systemet snabbt. Men det kan också avbryta användare som pausar naturligt mellan satser, vilket delar upp en tanke i flera segment och kan ge agenten för tidiga svar.
• En lång timeout (t.ex. ~800-1200 ms) tillåter naturliga pauser och håller yttranden intakta, men ger en märkbar fördröjning innan systemet reagerar.

Det finns ingen global konstant här – justera tröskeln efter interaktionen:

• Diktering och anteckningar klarar längre pauser eftersom användaren tänker mitt i meningen. Välj längre timeouts och använd VAD.
• Kommandon och transaktionsagenter mår bäst av kortare timeouts plus manuell commit, eftersom turerna är korta och tydliga.
• Flerspråkiga eller icke-modersmålstalare pausar mer, så ge mer tystnad innan du avslutar.

Med dessa tips bygger du ett effektivt end-pointing-system och närmar dig tal till text i realtid.

In-stream-funktioner: språkigenkänning och talaridentifiering

Strömmande igenkänning kan göra mer än att bara ge ord. Men varje extra signal du ber om påverkar fördröjning och stabilitet. Tumregeln är att bara slå på det som behövs för live-upplevelsen och spara resten till batch.

Automatisk språkigenkänning låter Scribe v2 Realtime identifiera språket bland sina 90+ språk istället för att du måste ange det i förväg. Nackdelen är att modellen behöver en kort ljudsnutt för att bli säker, så de första deltranskriptionerna kan vara mindre stabila medan språket bestäms. Om du redan vet språket, ange det – det ger stabilare deltranskriptioner direkt.

Talaridentifiering kopplar tal till olika personer och visar vem som sa vad. I batchtranskription är det lättare eftersom modellen ser hela filen. I strömmande läge är det svårare: igenkännaren måste gissa talare utifrån det ljud som kommit in, och etiketten kan behöva ändras när mer av talarens röst hörs. Hantera talaretiketter på samma sätt som deltranskriptioner: provisoriska tills segmentet är klart.

Tidsstämpling på ordnivå och entitetsigenkänning fungerar likadant. Ju mer metadata du vill ha per token, desto mer måste både modellen och nätverket hantera. För de flesta realtidsgränssnitt räcker det med text och segmentgränser live – detaljerad metadata kan du ta ut i efterhand med Scribe v2.

Ljudformat för strömmande: PCM och mu-law

Transport och igenkänning får mest uppmärksamhet, men många buggar i verkligheten kommer från hur du kodar och delar upp ljudet. Att välja rätt format och bitstorlek är det enklaste sättet att minska fördröjningen för tal till text.

PCM (linjärt, 16-bitars signed, little-endian) är formatet att använda när du kontrollerar inspelningen. Högre samplingsfrekvens ger mer detaljer: 16 kHz är standard för taligenkänning och räcker oftast; 8 kHz är telefonkvalitet och tappar diskant. Använd den frekvens som matchar din källa. Det finns ingen vinst i att öka 8 kHz-telefoni till 48 kHz – informationen finns inte där.

Mu-law på 8 kHz är telefonformatet. Om du tar emot samtal från t.ex. Twilio kommer ljudet som 8 kHz mu-law, och du bör skicka det vidare i det formatet istället för att koda om det. Att matcha källformatet undviker artefakter och onödig konvertering.

Bitstorleken styr fördröjningen mest direkt. Du skickar ljud i bitar och igenkännaren ger deltranskriptioner när bitarna kommer. Mindre bitar ger tätare uppdateringar och lägre fördröjning till första deltranskriptionen; större bitar ger färre meddelanden och lite mer kontext per gång. Ett praktiskt intervall är 20–250 ms ljud per bit. Som exempel: vid 16 kHz mono 16-bit PCM är en sekund ljud 32 000 byte, så en 100 ms-bit är cirka 3 200 byte.

Spela in mikrofonljud i webbläsaren

I webbläsaren är Web Audio API med AudioWorklet rätt verktyg. Workleten körs på ljudtråden, tar emot ljud i små ramar och påverkas inte av huvudtrådens lagg som den äldre ScriptProcessorNode. Den konverterar webbläsarens float-samplar till 16-bit PCM och skickar dem till huvudtråden, som skickar dem vidare via WebSocket.

Kärnan i worklet-processorn är konverteringen från float till PCM:

// pcm-worklet.ts - registered via audioContext.audioWorklet.addModule()
class PCMWorklet extends AudioWorkletProcessor {
  process(inputs: Float32Array[][]) {
    const channel = inputs[0]?.[0]; // mono; Float32, range [-1, 1]
    if (!channel) return true;
    const pcm = new Int16Array(channel.length);
    for (let i = 0; i < channel.length; i++) {
      const s = Math.max(-1, Math.min(1, channel[i]));
      pcm[i] = s < 0 ? s * 0x8000 : s * 0x7fff;
    }
    // Transfer the buffer to the main thread without copying.
    this.port.postMessage(pcm.buffer, [pcm.buffer]);
    return true;
  }
}
registerProcessor("pcm-worklet", PCMWorklet);

Pipeline i kod

Pipeline har tre delar: en webbläsarklient som spelar in mikrofonen och strömmar PCM till din server, en Node-server som skickar ljudet till Scribe v2 Realtime och skickar tillbaka transkriptioner, samt en scriptbar klient som strömmar PCM från fil eller telefoni.

Servern skickar vidare istället för att exponera igenkännaren direkt mot webbläsaren av en viktig anledning: din ElevenLabs API-nyckel är hemlig och ska aldrig synas i klientkod. Servern håller nyckeln. Om du ändå behöver prata direkt från webbläsaren, skapa en kortlivad engångstoken på serversidan och ge klienten den istället för API-nyckeln.

Webbläsarklient

Klienten öppnar en WebSocket till din server, spelar in mikrofonen via workleten ovan och skickar varje PCM-ram direkt. Inkommande händelser (redan normaliserade av servern till { type, text }) styr del/slutgiltigt-läget:

// client.ts - runs in the browser. ws is an open WebSocket to your server.
const audioContext = new AudioContext({ sampleRate: 16000 });
await audioContext.audioWorklet.addModule("pcm-worklet.js");

const mediaStream = await navigator.mediaDevices.getUserMedia({
  audio: { channelCount: 1, echoCancellation: true, noiseSuppression: true },
});

const source = audioContext.createMediaStreamSource(mediaStream);
const worklet = new AudioWorkletNode(audioContext, "pcm-worklet");

// Forward each PCM frame to the server the moment it is produced.
worklet.port.onmessage = (e: MessageEvent<ArrayBuffer>) => {
  if (ws.readyState === WebSocket.OPEN) ws.send(e.data);
};
source.connect(worklet);

// Manual commit: tell the server to finalize the current segment.
const commit = () => ws.send(JSON.stringify({ type: "commit" }));

Server-relä

Servern öppnar en igenkännaranslutning per klient, håller API-nyckeln på servern, skickar binär PCM rakt igenom och normaliserar igenkännarhändelser till det stabila { type, text }-formatet som klienten använder:

// server.ts - Node, using the `ws` library. ELEVENLABS_API_KEY and the
// recognizer URL come from the environment; see the Speech to Text reference
// for the exact path and query parameters.
import { WebSocketServer, WebSocket } from "ws";

new WebSocketServer({ port: 8080 }).on("connection", (client) => {
  // The API key stays on the server, never on the wire to the browser.
  const recognizer = new WebSocket(process.env.RECOGNIZER_WSS_URL!, {
    headers: { "xi-api-key": process.env.ELEVENLABS_API_KEY! },
  });

  // Browser -> recognizer: forward binary PCM, translate control messages.
  client.on("message", (data, isBinary) => {
    if (recognizer.readyState !== WebSocket.OPEN) return;
    if (isBinary) recognizer.send(data); // raw PCM bytes
    else if (JSON.parse(data.toString()).type === "commit")
      recognizer.send(sendCommit());
  });

  // Recognizer -> browser: normalize events into a stable shape.
  recognizer.on("message", (raw) => {
    const event = parseRecognizerEvent(raw.toString());
    if (event && client.readyState === WebSocket.OPEN)
      client.send(JSON.stringify(event));
  });

  // ... open handshake, queueing pre-open audio, and teardown on close/error
});

Allt som är endpointspecifikt finns i de två adapterfunktionerna nedan. Byt ut fältnamnen mot de exakta från Speech to Text-referensen – resten av pipeline ändras inte:

// The single place that knows the recognizer's wire format.
const sendCommit = (): string => JSON.stringify({ type: "commit" });

type NormalizedEvent =
  | { type: "partial"; text: string }
  | { type: "final"; text: string }
  | { type: "vad"; speaking: boolean };

function parseRecognizerEvent(raw: string): NormalizedEvent | null {
  const msg = JSON.parse(raw);
  if (msg.is_final === true || msg.type === "final")
    return { type: "final", text: msg.text ?? "" };
  if (msg.type === "vad") return { type: "vad", speaking: !!msg.speaking };
  if (typeof msg.text === "string")
    return { type: "partial", text: msg.text };
  return null;
}

Scriptbar backend-klient

För backend-pipelines och för benchmarken nedan fungerar samma igenkännaranslutning utan webbläsare: läs PCM från valfri källa, skicka i realtidstakt och ta emot händelser. API-nyckel och URL hämtas från miljön, precis som på servern.

// stream-stt.ts - pace ~100ms chunks at real time, then commit the tail.
const SAMPLE_RATE = 16000, CHUNK_MS = 100;
const CHUNK_BYTES = (SAMPLE_RATE * 2 * CHUNK_MS) / 1000; // 3200 bytes
const ws = new WebSocket(process.env.RECOGNIZER_WSS_URL!, {
  headers: { "xi-api-key": process.env.ELEVENLABS_API_KEY! },
});

// Send: walk the PCM buffer in 100ms chunks, sleeping between to mimic a
// live source. For audio that already arrives in real time, drop the sleep.
async function sendAudio(pcm: Buffer) {
  for (let off = 0; off < pcm.length; off += CHUNK_BYTES) {
    ws.send(pcm.subarray(off, off + CHUNK_BYTES));
    await new Promise((r) => setTimeout(r, CHUNK_MS));
  }
  ws.send(JSON.stringify({ type: "commit" })); // finalize the trailing segment
}

// Receive: print partials in place, append finals.
ws.on("message", (raw) => {
  const e = parseRecognizerEvent(raw.toString());
  if (e?.type === "final") console.log(`[final]   ${e.text}`);
  else if (e?.type === "partial") process.stdout.write(`[partial] ${e.text}\r`);
});

Benchmarking av tal till text-fördröjning och word error rate

Fördröjning och word error rate varierar beroende på talare, språk, akustik, ljudlängd, din nätverksväg till varje leverantörs närmaste region och aktuell belastning på tjänsten.

Ett resultat från en laptop i en stad gäller inte för din produktion i en annan. Kör tester från infrastruktur som liknar produktion, på ljud som liknar dina riktiga data, och rapportera intervall och fördelningar istället för enstaka siffror.

De enda fördröjnings- och noggrannhetssiffror som spelar roll är de du mäter på ditt eget ljud från infrastruktur som liknar produktion. Här är en guide till benchmarking av tal till text-fördröjning.

Vad du ska mäta för tal till text-fördröjning

Här är de viktigaste mätvärdena du bör ta fram när du benchmarkar tal till text i realtid:

• Tid till första deltranskription: Från att första ljudbiten skickas till att första icke-tomma deltranskriptionen tas emot.
• Fördröjning från del till slutgiltig: Från sista ljudbiten i ett yttrande till slutgiltig transkription.
• Word error rate (WER): WER på slutgiltigt transkript mot mänsklig referens, beräknat likadant för alla system.
• Stabilitetsförändring: Hur många deltranskriptioner skrivs om innan segmentet avslutas. Det visar hur mycket live-gränssnittet kommer att ändras.

Kontroller

För att undvika opålitliga data bör du införa flera kontroller i ditt test för att hålla allt konsekvent.

Här är de viktigaste kontrollerna för benchmarking av tal till text-fördröjning:

• Identiskt ljud: Använd samma filer, samma samplingsfrekvens och samma kodning till varje system.
• Identisk takt: Strömma varje system med samma realtidstakt (t.ex. 100 ms-bitar).
• Upprepa och rapportera fördelningar: Kör varje fil många gånger under dagen; rapportera median och topp (p50/p95).
• Identiska referenser och poäng: Normalisera texten likadant (gemener, skiljetecken, siffror) innan du beräknar WER.
• Redovisa region och nätverk: Ange var testet kördes och vägen till varje leverantör.

Genom att hålla allt detta lika får du mer exakta mätvärden.

Testharness-skelett

Mätkärnan tar en leverantörsadapter och loggar tid till första deltranskription, fördröjning till slutgiltig och omskrivningar av deltranskriptioner:

// benchmark.ts - measurement core; one StreamFn adapter per provider.
type StreamFn = (
  audioPath: string,
  onEvent: (kind: "partial" | "final", text: string) => void,
  result: RunResult
) => Promise<void>; // adapter sets result.lastChunkSentAt on the final chunk

interface RunResult {
  firstPartialMs?: number;
  finalLagMs?: number;
  hypothesis: string;
  partialEdits: number;
  lastChunkSentAt: number;
  startedAt: number;
}

async function measure(streamFn: StreamFn, audioPath: string): Promise<RunResult> {
  const result: RunResult = {
    hypothesis: "", partialEdits: 0, lastChunkSentAt: 0,
    startedAt: performance.now(),
  };
  let prevPartial = "";

  await streamFn(audioPath, (kind, text) => {
    const now = performance.now();
    if (kind === "partial") {
      if (text && result.firstPartialMs === undefined)
        result.firstPartialMs = now - result.startedAt;
      if (text !== prevPartial) { result.partialEdits++; prevPartial = text; }
    } else { // final
      result.hypothesis = result.hypothesis ? `${result.hypothesis} ${text}` : text;
      if (result.lastChunkSentAt)
        result.finalLagMs = now - result.lastChunkSentAt;
    }
  }, result);

  return result;
}

Word error rate är standard-Levenshtein-avstånd på token-nivå över normaliserad text. Gör gemener och ta bort skiljetecken på både referens och hypotes innan du räknar, annars mäter du din normalisering istället för modellen. Kör detta i en loop som testar varje fil ~10 gånger per leverantör och rapporterar median för tid till första deltranskription och median WER (p50/p95), eftersom enstaka mätningar påverkas mycket av nätverket.

För att köra det behöver du två saker. Först, skriv en StreamFn-adapter per system. Den scriptbara klienten ovan är redan en, och adaptrar för andra följer samma (audioPath, onEvent, result)-kontrakt och sätter result.lastChunkSentAt när sista ljudbiten skickas. Sedan laddar du dina ljudfiler och referenser och kör mätningarna. Kör från en maskin som liknar din produktion, på ljud som liknar dina användares, så får du en jämförelse du kan återskapa.

Sammanfattning: så får du tal till text i realtid

Vi har gått igenom många arkitekturförändringar i den här artikeln, så att du stegvis kan förbättra ditt system och närma dig tal till text i realtid.

Ett produktionssystem för tal till text i realtid handlar om några få beslut:

• Transport: Välj WebSocket för enkelhet och kontrollerade nätverk, och WebRTC när du behöver tåla förlust och spelar in från konsumentenheter.
• Deltranskriptioner och slutgiltiga: Behandla deltranskriptioner som provisoriska och slutgiltiga som bekräftade, och visa dem olika så användarna litar på texten.
• End-pointing: Använd VAD för handsfree-segmentering, manuell commit som överskrivning och justera tystnadströskeln efter interaktionen – inte en konstant.
• In-stream-funktioner: Slå bara på in-stream-funktioner där live-upplevelsen kräver det, och spara resten till batch med Scribe v2.
• Ljudformat: Spela in i små PCM-ramar, skicka ~100 ms-bitar och matcha källformatet för telefoni.
• Benchmarking: Justera noggrannhet mot fördröjning utifrån ditt eget ljud och mål.
• API-säkerhet: Håll din API-nyckel på servern, eller skapa engångstokens för direkta klientanslutningar.

Vill du se hur du kan optimera fördröjning i en voice agent? Vi har också skrivit en guide för dig.

Bygg tal till text-system i realtid med Scribe v2 Realtime

Scribe v2 Realtime ger deltranskriptioner på cirka 150 ms modellfördröjning. Om dina användare upplever den siffran eller något högre beror på arkitekturen runt omkring – det är den du styr över. Med strategierna i den här artikeln bygger du pipelines med lägre fördröjning och bättre kundupplevelse.

Vill du veta mer? Upptäck Speech to Text-funktionerna i översikten, läs vår modellreferens för hela funktions- och språklistan, och besök produktsidorna för realtid: realtids Speech to Text API och realtids Speech to Text.

När du är redo att börja bygga, skapa ett gratis ElevenLabs-konto och strömma din första transkription redan idag.

Vanliga frågor om tal till text i realtid och fördröjning