Voz a Texto en Tiempo Real en menos de 200 ms: Guía de arquitectura

Voz a texto en tiempo real (STT) transcribe el audio mientras la persona habla, devolviendo el texto en unos pocos cientos de milisegundos. Pero mantener la latencia baja depende tanto de la arquitectura como del modelo. Hay que planificar bien el transporte, el troceado, la detección de final de frase y la captura, ya que cada parte suma latencia. Si alguna de estas partes es ineficiente, puedes superar fácilmente el límite de 200ms.

Esta guía te ofrece un sistema práctico para construir flujos de voz a texto en tiempo real desde la capa de transporte. Nos centraremos en Scribe v2 en Tiempo Real, que genera transcripciones parciales en unos 150ms de latencia de modelo, soporta más de 90 idiomas, acepta audio PCM (8kHz-48kHz) y mu-law, e incluye Detección de Actividad de Voz y control manual de commit para finalizar segmentos.

Veremos cómo llega el audio al servidor, cómo las hipótesis se convierten en texto final, qué coste tienen las funciones en streaming y cómo capturar y enviar el audio correctamente.

Resumen rápido

• Crear sistemas de voz a texto en tiempo real requiere ajustar la arquitectura para mantener la latencia baja en todo el flujo.
• WebSocket es la opción adecuada para la mayoría de flujos, aunque WebRTC ofrece ventajas si puedes asumir su mayor complejidad.
• La Detección de Actividad de Voz permite segmentar sin manos, y el commit manual da a tus aplicaciones el control cuando saben que el turno ha terminado.
• Las transcripciones parciales son provisionales y las finales están confirmadas, así que deberías mostrarlas de forma diferente.
• Trocea el PCM en fragmentos pequeños de unos 100ms para minimizar la latencia hasta la primera parcial.

WebSocket vs. WebRTC para voz a texto en tiempo real

Antes de transcribir, el audio tiene que viajar desde el origen hasta el reconocedor. El canal que elijas marca la latencia mínima de todo el flujo. Hay dos opciones viables para que el audio llegue a la capa de transcripción.

WebSocket es un canal bidireccional, ordenado y fiable sobre TCP. Abres una conexión, envías tramas de audio binario y recibes eventos de transcripción. Es sencillo tanto en cliente como en servidor, atraviesa proxies y cortafuegos corporativos que ya permiten HTTPS, y todos los navegadores y servidores lo soportan.

La limitación de WebSocket es que funciona sobre TCP. Si se pierde un paquete, TCP lo retransmite y retiene los datos posteriores hasta rellenar el hueco. Con buena red no se nota, pero si hay pérdidas, se produce un bloqueo momentáneo y el audio se acumula y llega de golpe.

WebRTC está pensado para medios en tiempo real. Usa UDP (vía SRTP), así que si se pierde un paquete, el flujo sigue; el pipeline no se detiene. Incluye un buffer de jitter para absorber variaciones en la llegada de paquetes, negocia NAT con ICE/STUN/TURN para conectar dispositivos tras routers y lleva su propio sistema de captura y codificación de audio.

Normalmente necesitas servidores TURN para clientes que no pueden conectar directamente, y el servidor debe terminar un flujo de medios en vez de leer un flujo de bytes.

Aquí tienes el resumen de ventajas e inconvenientes:

Para la mayoría de casos, WebSocket es la mejor opción. Úsalo cuando tus clientes tengan buena conectividad y controles la captura: flujos server-to-server, apps de escritorio, apps web en banda ancha y la mayoría de backends de contact centers donde el audio ya llega a tu servidor.

Elige WebRTC cuando captures directamente de dispositivos de usuario en redes móviles poco fiables, cuando ya uses WebRTC para audio bidireccional (por ejemplo, un agente de voz que también responde) o cuando la tolerancia a pérdidas sea más importante que la simplicidad.

El resto de esta guía usa WebSocket como transporte para la conexión con el reconocedor, porque mantiene todo visible y es el punto de partida ideal para la mayoría. Nada es exclusivo de WebSocket, así que puedes añadir luego una capa WebRTC delante, decodificar el audio a PCM en el servidor y enviar los mismos fragmentos al flujo.

Parciales y finales: cómo funcionan los resultados intermedios

Un reconocedor en tiempo real no espera a la frase completa para responder. Va generando hipótesis que se afinan a medida que llega más audio y luego las fija. Entender la diferencia entre estos dos estados es clave para que la transcripción parezca viva y no rota.

Una hipótesis parcial es la mejor suposición del modelo con el audio recibido hasta ese momento. Las parciales son inestables por diseño. Al llegar más audio, el modelo puede corregir palabras anteriores: "quiero" puede pasar a ser "quiero dos entradas" cuando el contexto lo aclara. Llegan rápido (de ahí los ~150ms de latencia) y están pensadas para sobrescribirse.

Una hipótesis final es un segmento confirmado que ya no cambiará. Una vez finalizado, el reconocedor sigue con el siguiente segmento y las siguientes hipótesis describen audio posterior. Las finales son las que guardas, envías a un LLM o almacenas como transcripción.

La diferencia entre parciales y finales afecta a tres cosas que puedes hacer mal si las confundes:

• Experiencia de usuario: Mostrar parciales hace que la transcripción parezca en vivo: el usuario ve aparecer palabras mientras habla, lo que confirma que el micro funciona y el sistema escucha.
• Final de frase: Las parciales te dan una señal continua de actividad de voz. Combinadas con VAD, te permiten decidir cuándo el hablante ha terminado.
• Sincronización posterior: En un flujo de agente de voz los pasos son: audio de entrada, luego voz a texto, después un LLM, y luego

Muestra parciales y finales de forma diferente. Un patrón sencillo y eficaz es mantener una "línea actual" mutable con la última parcial y pasarla a la transcripción definitiva cuando llegue una final:

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: "" });

Visualmente, muestra las finales como texto fijo y la actual en un estilo más claro o en cursiva para que el usuario sepa que puede cambiar.

Final de frase y detección de actividad de voz (VAD)

Saber qué se ha dicho es solo la mitad del reto. El reconocedor también debe saber cuándo termina una idea. Esa decisión marca cuándo finalizas un segmento y, en un agente, cuándo empieza a responder el sistema.

El final de frase es la decisión de que una intervención ha terminado. Si finalizas demasiado pronto, cortas al usuario a mitad de frase. Si finalizas demasiado tarde, el agente se queda callado aunque el usuario ya haya terminado.

Scribe v2 Realtime te da dos mecanismos complementarios:

• La Detección de Actividad de Voz segmenta el audio según los silencios: El reconocedor detecta cuándo la voz da paso a un silencio sostenido y usa ese límite para finalizar el segmento automáticamente. VAD es la opción por defecto para interfaces conversacionales porque se adapta al ritmo natural del habla sin que tengas que controlar los tiempos.
• Control manual de commit: El control manual de commit permite que tu aplicación decida cuándo finalizar el segmento actual, independientemente del silencio. Envías una señal de commit, el reconocedor cierra el segmento y emite una final. Es útil cuando tu app ya sabe que el turno ha terminado: al soltar un botón de pulsar para hablar, al pulsar "enviar" o por una política externa de turnos.

Ambos mecanismos se pueden combinar. Un agente de voz típico usa VAD para funcionar sin manos y expone el commit manual como opción extra, así si el usuario se para a pensar no se le corta, pero si pulsa un botón obtiene un corte inmediato.

El umbral de silencio es un equilibrio real sin valor universal:

• Un tiempo de espera corto (por ejemplo, finalizar tras ~200-400ms de silencio) hace que el sistema responda rápido, pero puede cortar a usuarios que hacen pausas naturales, dividiendo una idea en varios segmentos y provocando respuestas prematuras.
• Un tiempo largo (por ejemplo, ~800-1200ms) tolera pausas naturales y mantiene las frases completas, pero añade un retardo visible antes de que el sistema reaccione.

No hay un valor global: ajusta el umbral según la interacción:

• En dictado y toma de notas se toleran pausas largas porque el usuario piensa a mitad de frase. Mejor tiempos largos y VAD.
• En agentes de comandos o transacciones convienen tiempos cortos y commit manual, porque los turnos son breves y directos.
• Hablantes multilingües o no nativos suelen pausar más, así que deja más silencio antes de finalizar.

Con estos consejos puedes construir un sistema de final de frase eficaz y acercarte a voz a texto en tiempo real.

Funciones en streaming: detección de idioma y diarización de hablantes

El reconocimiento en streaming puede hacer más que sacar palabras. Pero cada señal extra que pidas afecta a la latencia y la estabilidad. La regla es activar solo lo que la experiencia en vivo necesita y dejar el resto para un procesamiento por lotes.

El reconocimiento automático de idioma permite que Scribe v2 Realtime identifique el idioma hablado entre los más de 90 soportados, sin que tengas que indicarlo antes. El coste es que el modelo necesita unos segundos de audio para decidir con confianza, así que las primeras parciales pueden ser menos estables mientras se determina el idioma. Si ya sabes el idioma, especificarlo elimina esa ambigüedad y suele dar parciales más estables al principio.

La diarización de hablantes asigna el habla a personas distintas, identificando quién dice qué. En transcripción por lotes es fácil porque el modelo ve todo el archivo. En streaming es más difícil: el reconocedor debe asignar una etiqueta de hablante solo con el audio recibido, y puede que tenga que corregirla cuando escuche más de esa voz. Trata las etiquetas de hablante igual que el texto parcial: provisionales hasta que se finaliza el segmento.

El tiempo por palabra y el contexto de entidades siguen la misma lógica. Cuantos más metadatos por token pidas, más carga para el modelo y la red. Para la mayoría de interfaces en tiempo real solo necesitas el texto y los límites de segmento en vivo; los metadatos detallados puedes procesarlos después con Scribe v2.

Formatos de audio para streaming: PCM y mu-law

El transporte y la lógica de reconocimiento suelen llevarse la atención, pero muchos fallos reales vienen de una capa más abajo: cómo codificas y troceas el audio. Elegir bien el formato y el tamaño de fragmento es la forma más sencilla de reducir la latencia en voz a texto.

PCM (lineal, 16 bits, little-endian) es el formato a usar si controlas la captura. Tasas de muestreo más altas recogen más detalle: 16kHz es el mínimo estándar para reconocimiento y suele bastar; 8kHz es calidad telefónica y pierde agudos. Usa la tasa que tenga tu fuente. No sirve de nada subir de 8kHz a 48kHz si el audio original no tiene esa información.

Mu-law a 8kHz es el formato telefónico. Si recibes llamadas de un proveedor como Twilio, el audio llega en mu-law 8kHz y deberías reenviarlo así, sin transcodificarlo dos veces. Mantener el formato de origen evita artefactos y conversiones innecesarias.

El tamaño de fragmento es lo que más afecta a la latencia percibida. Envías el audio en fragmentos y el reconocedor genera parciales según llegan. Fragmentos pequeños dan actualizaciones más frecuentes y menor latencia hasta la primera parcial; fragmentos grandes suponen menos mensajes y algo más de contexto por inferencia. Un rango práctico es 20-250ms por fragmento. Por ejemplo, en PCM mono 16kHz 16 bits, un segundo son 32.000 bytes, así que un fragmento de 100ms son unos 3.200 bytes.

Captura de micro en el navegador

En el navegador, la mejor opción es la Web Audio API con un AudioWorklet. El worklet corre en el hilo de audio, recibe el audio en pequeños frames y no sufre los bloqueos del hilo principal como el antiguo ScriptProcessorNode. Su función es convertir los samples float del navegador a PCM 16 bits y pasarlos al hilo principal, que los envía por WebSocket.

El núcleo del procesador worklet es la conversión de float a 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);

El pipeline en código

El flujo tiene tres partes: un cliente web que captura el micro y envía PCM al servidor, un servidor Node que reenvía el audio a Scribe v2 Realtime y devuelve las transcripciones, y un cliente scriptable que envía PCM desde un archivo o puente telefónico.

El servidor reenvía en vez de exponer el reconocedor directamente al navegador por una razón importante: tu clave de API de ElevenLabs es secreta y nunca debe aparecer en el código cliente. El servidor guarda la clave. Si necesitas que el navegador hable directamente con el reconocedor, genera un token de un solo uso en el servidor y pásaselo al cliente en vez de la clave.

Cliente web

El cliente abre un WebSocket con tu servidor, captura el micro con el worklet anterior y reenvía cada frame PCM según se produce. Los eventos entrantes (ya normalizados por el servidor como { type, text }) gestionan el estado parcial/final:

// 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" }));

Servidor relay

El servidor abre una conexión con el reconocedor por cliente, guarda la clave de API en el servidor, reenvía el PCM binario tal cual y normaliza los eventos del reconocedor al formato estable { type, text } que consume el cliente:

// 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
});

Todo lo específico de la ruta de API está en las dos funciones adaptadoras de abajo. Cambia los nombres de campo por los de la referencia de Voz a Texto; el resto del flujo no cambia:

// 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;
}

Cliente backend scriptable

Para flujos backend y para el benchmark de abajo, la misma conexión con el reconocedor funciona sin navegador: lee PCM de cualquier fuente, envíalo al ritmo real y recibe los eventos. La clave de API y la URL vienen del entorno, igual que en el servidor.

// 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`);
});

Benchmark de latencia y tasa de error de palabra en voz a texto

La latencia y la tasa de error de palabra varían según el hablante, el idioma, las condiciones acústicas, la duración del audio, tu red hasta la región más cercana de cada proveedor y la carga actual de cada servicio.

Un resultado medido en un portátil de una ciudad no se aplica a tu infraestructura de producción en otra. Haz las pruebas en sistemas parecidos a producción, con audio similar al real, y reporta rangos y distribuciones, no solo un número.

Las únicas cifras de latencia y precisión que importan son las que midas con tu propio audio y en una infraestructura similar a producción. Aquí tienes una guía para medir la latencia de voz a texto.

Qué medir en la latencia de voz a texto

Estos son los principales indicadores que debes medir al comparar latencia en voz a texto en tiempo real:

• Tiempo hasta la primera parcial: Desde que envías el primer fragmento de audio hasta que recibes la primera parcial no vacía.
• Retraso de parcial a final: Desde el último fragmento de audio de una intervención hasta la hipótesis final.
• Tasa de error de palabra (WER): WER sobre la transcripción final comparada con una referencia humana, calculado igual en todos los sistemas.
• Estabilidad (churn): Cuántas parciales se reescriben antes de finalizar. Es un indicador de cuánto cambia la UI en vivo.

Controles

Para evitar datos poco fiables, deberías aplicar varios controles en tu experimento para mantener la consistencia.

Estos son los principales controles para comparar latencia en voz a texto:

• Audio idéntico: Usa los mismos archivos, misma tasa de muestreo y misma codificación para todos los sistemas.
• Ritmo idéntico: Envía todos los sistemas al mismo ritmo real (por ejemplo, fragmentos de 100ms).
• Repite y reporta distribuciones: Ejecuta cada archivo varias veces al día; reporta mediana y extremos (p50/p95).
• Referencias y puntuación idénticas: Normaliza el texto igual (mayúsculas, puntuación, números) antes de calcular el WER.
• Indica región y red: Di dónde se ejecutó la prueba y la ruta a cada proveedor.

Si mantienes todos estos elementos iguales, obtendrás métricas más precisas.

Esqueleto del benchmark

El núcleo de la medición toma un adaptador de proveedor y registra tiempo hasta la primera parcial, retardo de finalización y churn de parciales:

// 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;
}

La tasa de error de palabra es una distancia Levenshtein estándar a nivel de token sobre texto normalizado. Pasa todo a minúsculas y quita la puntuación igual en referencia e hipótesis antes de calcular, o medirás tu normalizador y no el modelo. Hazlo en un bucle que ejecute cada archivo unas 10 veces por proveedor y reporta la mediana de tiempo hasta la primera parcial y WER (p50/p95), ya que una sola muestra depende mucho de la red.

Para ejecutarlo, necesitas dos cosas. Primero, escribe un adaptador StreamFn por sistema. El cliente scriptable de arriba ya es uno, y los adaptadores para los demás siguen el mismo contrato (audioPath, onEvent, result) y marcan result.lastChunkSentAt cuando se envía el último fragmento. Segundo, carga tus archivos de audio y referencias y llama a las mediciones. Hazlo desde una máquina similar a tu despliegue, con audio representativo de tus usuarios, y tendrás una comparación reproducible.

Resumen: cómo conseguir voz a texto en tiempo real

Hemos repasado muchos cambios de arquitectura en este artículo, para que puedas mejorar tu sistema paso a paso y acercarte a voz a texto en tiempo real.

Un sistema de STT en tiempo real en producción depende de unas pocas decisiones:

• Transporte: Elige WebSocket por simplicidad y redes controladas, y WebRTC si necesitas tolerancia a pérdidas y capturas desde dispositivos de usuario.
• Parciales y finales: Trata las parciales como provisionales y las finales como confirmadas, y muéstralas diferente para que los usuarios confíen en el texto en vivo.
• Final de frase: Usa VAD para segmentar sin manos, commit manual como opción extra y ajusta el umbral de silencio según la interacción, no como valor fijo.
• Funciones en streaming: Activa funciones en streaming solo donde la experiencia en vivo lo requiera y deja el resto para procesamiento por lotes con Scribe v2.
• Formato de audio: Captura en frames PCM pequeños, envía fragmentos de ~100ms y mantén el formato de origen para telefonía.
• Benchmark: Ajusta la precisión y la latencia de forma empírica con tu propio audio y métrica objetivo.
• Seguridad de la API: Guarda tu clave de API en el servidor, o genera tokens de un solo uso para conexiones directas de cliente.

Si quieres ver cómo optimizar la latencia en un agente de voz, también hemos preparado una guía para ti.

Crea sistemas de voz a texto en tiempo real con Scribe v2 Realtime

Scribe v2 Realtime genera parciales en unos 150ms de latencia de modelo. Que tus usuarios experimenten esa cifra o una mayor depende de la arquitectura que montes alrededor, que es lo que puedes controlar. Si aplicas las estrategias de este artículo, construirás flujos optimizados que reducen la latencia y mejoran la experiencia.

Si quieres profundizar, descubre el resumen de capacidades de Voz a Texto, consulta nuestra referencia de modelos para ver todas las funciones e idiomas, y visita las páginas de producto en tiempo real: API de Voz a Texto en tiempo real y Voz a Texto en tiempo real.

Cuando quieras empezar, crea una cuenta gratuita en ElevenLabs y transmite tu primera transcripción hoy mismo.

Preguntas frecuentes sobre latencia en voz a texto en tiempo real