KINTO reemplazó el streaming de pago de una emisora comunitaria por infraestructura propia: latencia de ≈10 s a menos de 1 s y un costo mensual que cayó en más de un 90 %.
Problema
La emisora transmitía en línea con un servicio de terceros de pago, con latencia alta, sin control del stream ni métricas reales de oyentes, y dependía del proveedor para aparecer en directorios de radios.
Señales
- Mercado: Audiencia local que escucha por web y móvil; los directorios de radio exigen un stream compatible.
- Negocio: Costo recurrente y objetivo de cientos de oyentes simultáneos a costo casi cero.
- Experiencia de usuario: Latencia y cortes; redes escolares y corporativas que bloquean ciertos protocolos.
- Atención al cliente: WhatsApp y redes en el reproductor; widget para el sitio institucional.
Cómo lo entendimos
- Especificación previa y pruebas de latencia por protocolo.
- Diagnóstico de un fallo difícil de audio mudo en la infraestructura.
- Analítica con el oyente a 30 segundos como métrica clave.
Qué construimos y por qué
- App de transmisión para el PC de la emisora.
- Servidor en la nube con varias salidas (tiempo real, baja latencia y formato compatible con directorios) que se reinicia solo.
- Reproductor web con degradación automática de protocolo y widget embebible para el sitio institucional.
Por qué así: Algunas redes bloquean ciertos protocolos, así que el reproductor degrada solo de uno a otro, y el servidor ofrece tres salidas (tiempo real, baja latencia y formato compatible con directorios).
Transformación
-
Latencia de ≈10 s a ≈0,3–0,8 s en tiempo real (≈2–3 s en baja latencia).
-
Costo mensual reducido en más de un 90 %.
-
latencia en modo tiempo real: de ≈10 s a ≈0,3–0,8 s (medido)
-
costo mensual de transmisión: ≈−90 % o más (medido)
Lo que aún no sabemos
- Audiencia y retención: sin evidencia.
