Volvemos al blog tras el parón de verano, y lo hacemos con un altavoz conversacional voz-a-voz que hemos montado en el laboratorio: el FVL-01, primer prototipo del Faktoria Voice Lab.
Es de esos proyectos que en Faktoria hacemos sin que tengan que acabar en producto: sirven para llegar a las conversaciones con las manos manchadas, no con vídeos de fabricantes. Lo contamos en dos capas, la friki (esquemas, código, tropiezos) y la de empresa (los casos de uso reales que ya cubre este stack y cómo se integra con Konect, nuestra plataforma centralizada de análisis y tratamiento conversacional).
Qué es el FVL-01, nuestro altavoz conversacional voz-a-voz
El FVL-01, primer prototipo del Faktoria Voice Lab, es un altavoz conversacional voz-a-voz sobre una placa Seeed ReSpeaker XVF3800 con un XIAO ESP32-S3. Habla, escucha, sigue con el haz de micrófonos a quien habla (direction of arrival) y aloja, hasta donde sabemos, el primer cliente LiveKit sobre ESP32 escrito en Zig. Coste en reposo: cero euros; en uso moderado con speech-to-speech nativo: unos 10 $ al mes.
Lo importante no es el altavoz, sino lo que demuestra: que hoy se puede montar, con componentes accesibles y software libre, una plataforma de voz conversacional de calidad producto (latencia por debajo del segundo, buena cancelación de eco, barge-in real y observabilidad completa), y que esa misma plataforma sirve para un contact center, un quiosco de atención ciudadana o una sala de reuniones. Cambia la carcasa, no el stack.
El camino del audio (y lo que se rompió)
La pieza que manda es el XVF3800, un DSP de voz de XMOS: el array de cuatro micrófonos se conecta a él y ahí sucede el trabajo sucio (beamforming, cancelación de eco, supresión de ruido). El ESP32-S3 solo mueve PCM entre el bus I2S y la red. Cuatro reglas que aprendimos a golpes: el XVF es maestro I2S y el ESP32 esclavo, con puertos separados para micro y altavoz (un canal duplex tumbaba la placa); la captura va sin ring buffer, porque un buffer libre sonaba, literalmente, a helicóptero por la deriva de reloj; una sola pasada de supresión de ruido, porque dos en serie dejaban un artefacto metálico; y el audio se renderiza a 32 bits (a 16 sonaba sucio) antes de salir por el codec AIC3104.
La confesión más honesta es la del cancelador de eco: no convergía, y el primer «fix» que publicamos era, sin anestesia, un placebo. El arreglo real estaba en el gain de referencia y en activar el DSP del far-end:
/// after the ESP sw-vol and the AIC3104 is 0 dB → 0.0 (factory) is correct.
/// The 1.0 we shipped earlier was a placebo from the FAR_EXTGAIN misdiagnosis.
pub fn applyConfig() bool {
if (!writeF32Verified(RESID_AUDIO_MGR, MGR_REF_GAIN, 1.0, «REF_GAIN»)) return false;
if (!writeF32Verified(RESID_AEC, AEC_FAR_EXTGAIN, 0.0, «FAR_EXTGAIN»)) return false;
if (!writeF32Verified(RESID_AUDIO_MGR, MGR_MIC_GAIN, 90.0, «MIC_GAIN»)) return false;
if (!writeU8Verified(RESID_AUDIO_MGR, MGR_FAR_END_DSP_ENABLE, 1, «FAR_END_DSP_ENABLE»)) return false;
return true;
}
El resultado: 38,5 dB de SNR frente a los 30,7 dB del beam crudo, y de regalo, full-duplex con tracking (se puede interrumpir al altavoz mientras habla). El barge-in de verdad fue otra batalla: como el modelo genera audio más rápido que el tiempo real, cancelar la generación no basta, así que el agente publica un evento interrupted y el firmware vacía la FIFO de render. La regla que sostiene todo lo demás: una sola pasada de supresión de ruido, y no confundir nunca un placebo con un parche real.
La palabra que lo despierta
La escucha es local: un modelo microWakeWord, una CNN de streaming de 62 KB, decide en el propio dispositivo cuándo abrir sesión, así que la sala LiveKit se abre solo bajo demanda y el coste en reposo es cero. Entrenamos una wake word propia en español, «Faktoria» (18.220 muestras positivas, unos 20 GB de negativos y un recall del 99,29 % en validación), pero en uso real colaba demasiados falsos positivos, así que hoy el dispositivo embarca el modelo stock en inglés «Okay Nabu» con el umbral subido; recuperar la versión en español sigue en el roadmap.
La integración fue una guerra de cinco bugs, el peor invisible (el estado interno de la CNN no se reseteaba entre armados) y el más caro de encontrar por aliasing al diezmar de 48 a 16 kHz sin filtro. Hoy recall y precisión viven en capas distintas: la placa mantiene el umbral laxo para no perder activaciones, y el agente re-verifica cada disparo transcribiendo el pre-roll, así que cada rechazo alimenta solo el dataset de negativos difíciles.
Firmware en Zig, con un truco
La aplicación está escrita en Zig sobre ESP-IDF; el core WebRTC queda en C, porque el SDK de LiveKit no se reescribe, y los bindings se escriben a mano porque el translate-c de Zig se atraganta con las cabeceras de ESP-IDF. El truco que más nos gusta: el propio código Zig flashea el XVF3800 por DFU en el primer arranque, con la imagen de fábrica intacta como red de seguridad, así que no hay forma de brickearlo. El ESP32-S3 va justo de RAM, así que el firmware se congela y las funciones nuevas van al servidor: añadir un micrófono a otra habitación es flashear otra unidad, sin tocar firmware.
El otro lado del cable: el agente
El agente es Python sobre LiveKit Agents con un modelo speech-to-speech nativo (Gemini por defecto, gpt-realtime-mini como reserva) y un VAD local (Silero) para el barge-in instantáneo. Las acciones del entorno se tocan vía MCP: contra Home Assistant en el laboratorio, contra el back-office que toque en cliente. Y, contra la intuición, el pipeline clásico STT + LLM + TTS no es la opción barata: el TTS domina la factura.
| Pipeline | Latencia voz-a-voz | Coste mensual (uso moderado) |
|---|---|---|
| STT + LLM + TTS (clásico) | 1,3 – 2,1 s | 15 – 26 $ |
| Speech-to-speech nativo | 0,5 – 0,9 s | ≈ 10 $ |
Los modelos speech-to-speech nativos marcan el suelo de precio y, además, la mejor latencia voz-a-voz que hemos medido.
El plano de control
Detrás hay un servicio en Go, contract-first (el openapi.yaml genera tipos y router), cuyo endpoint POST /v1/sessions autentica el dispositivo y devuelve una credencial de corta vida sin secretos estáticos; cada sesión estrena sala, así que dos agentes respondiéndose entre sí es imposible por construcción. PostgreSQL es la fuente de verdad, y un worker entrega los cambios como CloudEvents durables en NATS JetStream. El SFU de LiveKit corre self-hosted en un clúster Talos por GitOps: audio local a la LAN y cero euros por minuto de sala.
La observabilidad es una única superficie: el agente exporta métricas y transcripciones vía OpenTelemetry a un stack Grafana, y el firmware espeja sus logs por syslog UDP. Diez días de banco de pruebas: 146 detecciones, 146 sesiones, cero pánicos y cero reinicios.
Manual: móntalo tú
Cualquiera con un banco de trabajo mínimo puede reproducir el FVL-01. Este es el manual que hubiéramos querido tener al empezar; no sustituye a la documentación de referencia, pero deja la ruta clara.
Lista de materiales:
| Componente | Rol | Coste aprox. |
|---|---|---|
| Seeed ReSpeaker XVF3800 | DSP XMOS + array 4 micros + AIC3104 | ~ 55 € |
| Seeed XIAO ESP32-S3 | MCU · WebRTC · runtime Zig | ~ 8 € |
| Altavoz 5 W (4 Ω) | Salida de audio | ~ 4 € |
| Fuente USB-C 5 V / 2 A | Alimentación | ~ 6 € |
| Carcasa impresa 3D (opcional) | Estética y acústica | ≈ 0 € |
| Servidor / VM Linux (agente + Go) | Plano de control · LiveKit SFU · Grafana | propio |
- Toolchain:
esp-idf(fork Xtensa) yzig 0.13+; el propio firmware flashea el XVF3800 por DFU en el primer arranque, sin ESPHome. - LiveKit self-hosted con Docker Compose.
- Plano de control en Go, con PostgreSQL y NATS JetStream.
- Agente Python (LiveKit Agents): modelo por variable de entorno, Silero VAD y los MCP necesarios.
- Wake word: empezar con el modelo stock y refinar con negativos difíciles capturados en uso.
- Instrumentación: OpenTelemetry, syslog UDP y un dashboard Grafana.
- Puerta a producción: autenticación, rate-limiting, OTA con rollback, cifrado de flash, grabación opt-in y verificación de hablante por turno.
Si todo funciona en el banco pero no sobrevive una semana desatendido en un salón, no está terminado: ese es el criterio de salida que usamos también en producción.
De qué sirve este altavoz conversacional voz-a-voz fuera del laboratorio
Cualquier organización que quiera bajar la interacción por voz al mismo nivel de calidad que hoy tiene una app puede construir su propio altavoz conversacional voz-a-voz sobre este stack. La diferencia con las soluciones cerradas es que aquí se controla el chip, el firmware, el transporte, el modelo y el plano de control. Estos son los casos en los que ya lo estamos aplicando o proponiendo dentro de Faktoria:
- Contact center inteligente. Voz-a-voz nativo delante de un agente automático de nivel 1, con barge-in real y transferencia caliente a IVOZ Provider cuando la conversación necesita un humano.
- Salas de reuniones y aulas. Asistente de sala que toma notas, controla la videoconferencia, la climatización o el proyector, y publica el resumen al final. Un solo dispositivo por sala, sin PC dedicado.
- Recepciones desatendidas 24×7. Hoteles, hospitales, clínicas, coworkings y edificios corporativos: bienvenida, tramitación básica y escalado a videollamada con un humano si hace falta.
- Quioscos de atención ciudadana. Ayuntamientos y administraciones que necesitan una puerta de entrada accesible, multilingüe y auditable a los trámites, integrada con su back-office.
- Retail y punto de venta. Consultas de producto, disponibilidad y pedidos por voz manos libres, para almacenistas y reponedores que no pueden usar el móvil todo el tiempo.
- Industria y campo. Órdenes de trabajo, partes y consultas técnicas por voz en entornos con las manos ocupadas o con EPI: el array de micrófonos con AEC del XVF3800 aguanta ruido industrial mucho mejor que un teléfono estándar.
- Sanidad y asistencia. Recordatorios, seguimiento de pacientes y llamadas asistidas para personas mayores, con verificación de hablante y grabación opt-in.
- IoT vertical con voz. Sensores, actuadores o cuadros de mando que ya existen en la empresa, expuestos como MCP y accesibles desde el agente: el altavoz deja de ser un juguete y se convierte en un mando por voz para el sistema real.
Ya hemos aplicado un stack de voz parecido en clientes reales: podéis ver algunos de esos proyectos en nuestros casos de éxito, y si os interesa el contexto de por qué apostamos por tecnología propia frente a soluciones cerradas, lo contábamos en ¿Está tu empresa lista para automatizar sus comunicaciones?.
Konect: el cerebro conversacional detrás del altavoz conversacional voz-a-voz
El altavoz es la punta visible. En una empresa, lo que da valor es todo lo que pasa después de que la conversación acabe, y cada vez más, mientras está ocurriendo. Ese es el papel de Konect, nuestra plataforma centralizada de análisis y tratamiento de conversaciones.
Cada sesión, venga por el FVL-01, por un contact center IVOZ, por un webphone o por un canal de mensajería, aterriza en Konect con la misma forma: audio, transcripción, metadatos técnicos, latencias y contexto de negocio. A partir de ahí, Konect analiza en tiempo real (detecta intents de negocio, evalúa satisfacción, identifica riesgos de fuga o incumplimiento normativo y dispara acciones sin esperar al post-mortem), trata y enriquece cada conversación (redacción automática de PII, resumen ejecutivo, categorización, tagging semántico y expedición a los sistemas verticales del cliente con el nivel de trazabilidad que exige RGPD/ENS) y alimenta el círculo de mejora: los rechazos del wake word, los turnos mal clasificados y las conversaciones marcadas por QA se convierten en dataset para afinar la wake word, el prompt del agente o, en clientes con volumen, un modelo especializado.
Arquitectónicamente, el FVL-01 encaja con Konect por dos vías. La primera, directa: los CloudEvents que ya publica el plano de control en NATS JetStream se enrutan al mismo Konect que reciben los eventos de IVOZ Provider. La segunda, homogénea: el agente Python emite las transcripciones turno a turno vía OpenTelemetry al mismo stack Grafana y backend de conversaciones que utiliza el resto de la voz corporativa. Nada específico del altavoz: mismo formato, misma trazabilidad, mismo panel. En cliente, esto significa que el día que se decida sustituir el FVL-01 por otro dispositivo, un contact center o un webphone, no cambia nada aguas abajo: la capa conversacional es la que gobierna, no el hardware.
La puerta entre el banco y el salón (y el cliente)
En el repo del proyecto hay un milestone que llamamos «living-room-ready». No es una lista de features, son criterios de salida, cada uno con su test: autenticación y rate-limiting en la superficie HTTP expuesta, OTA con rollback y cifrado de flash, grabación de sesiones opt-in con retención y consentimiento claros, y verificación de hablante por turno para que un altavoz de fondo no secuestre las sesiones. Esos mismos criterios son los que aplicamos cuando esto sale del laboratorio y va a un cliente real: no cambia el listón, y la definición de hecho es la misma en los dos escenarios, una semana desatendido y que cada fallo se pueda reconstruir desde Grafana sin tocar el cacharro.
Si os habéis quedado con ganas de más, el post original de Rubén García está en el blog de Zetesis y el repositorio del laboratorio es público en GitHub. Y si en vuestra empresa hay un caso al que le encajaría este altavoz conversacional voz-a-voz, contact center, quiosco, sala, industria, hablemos: llevamos casi treinta años poniendo voz en producción, y este experimento es la punta de hierro de lo que viene.