El stream de tu radio se va a caer. Hoy, la semana que viene, en medio del partido del domingo. El internet del estudio parpadea, la computadora del encoder se reinicia sola, alguien tropieza con el cable. Eso no se evita al cien por ciento, y quien promete lo contrario está vendiendo algo.
Lo que sí puedes decidir es otra cosa: cuando la señal se cae, ¿el oyente se cae con ella o se queda esperando y escuchando algo? Yo creo que la mayoría de las radios pequeñas no pierde oyentes en la caída, sino en los minutos que siguen. El reproductor se desconecta, el oyente piensa que la radio salió del aire y se va a otra. Y casi siempre eso se resuelve con tres ajustes que no cuestan nada.
Por qué el oyente se desconecta cuando cae el encoder
En Icecast, cada stream vive en un punto de montaje (el "mount", algo como /envivo). El encoder del estudio es la fuente que alimenta ese mount. Si la fuente deja de mandar audio, el servidor espera un poco y corta la conexión: la documentación de Icecast 2.4.1 llama a ese tiempo source-timeout, y su archivo de ejemplo usa 10 segundos.
Hasta ahí, normal. El problema es lo que pasa con quien está escuchando. La misma documentación es directa: sin un mount de respaldo configurado, los oyentes "will be disconnected" (quedan desconectados). La app se cierra, el reproductor de la web se detiene, el parlante inteligente de la cocina que pasa tu stream se queda mudo. Cuando el encoder vuelve, treinta segundos después, ya no hay nadie del otro lado. Cada uno tiene que darle play otra vez, y muchos no lo hacen.
El fallback que deja al oyente esperando
Icecast tiene una opción llamada fallback-mount. Le dice al servidor a dónde mandar a los oyentes si la fuente se cae. Puede ser otro mount, por ejemplo un segundo encoder en otro lugar, o un archivo de audio grabado. Del archivo, la documentación dice que se repite hasta que el oyente se desconecta o hasta que el stream vuelve y se lleva a la gente de regreso.
Para que esa vuelta ocurra sola, se activa una segunda opción en el mount principal, fallback-override. Con ella, cuando el encoder reconecta, los oyentes salen del respaldo y vuelven a la señal en vivo. Nadie toca nada.
Ahora, qué grabar en ese archivo. Yo no pondría silencio ni una canción suelta. Pondría la voz institucional de la radio diciendo el nombre de la emisora y que la señal vuelve enseguida, con una cortina musical debajo, unos dos minutos, algo que aguante repetirse sin cansar. Quien escucha sabe que la radio sigue ahí. Y hay un detalle técnico que agarra a mucha gente: el archivo tiene que estar en el mismo formato del stream. Si transmites MP3 a 128 kbps, el archivo es MP3 a 128 kbps, con la misma frecuencia de muestreo. Icecast advierte que un formato distinto puede dar problemas de reproducción.
Si tu servidor es contratado y no tienes acceso a la configuración, esa parte le toca al proveedor. Si usas el streaming de audio de Virtues o el de cualquier otra empresa, la pregunta es simple: ¿mi mount tiene fallback? ¿A dónde apunta? ¿El oyente vuelve solo?
El encoder tiene que volver sin nadie en el estudio
El segundo ajuste está en la computadora que manda el audio. Voy a usar BUTT como ejemplo, pero la lógica vale para el encoder que uses.
El manual de BUTT 1.47 dice que, si la conexión se pierde, intenta reconectar hasta que alguien presione stop. Muy bien. Pero eso no ayuda si el programa ni siquiera está abierto. Por eso hay dos casillas que yo marcaría: la que inicia BUTT junto con Windows y "Start streaming after launch", que conecta al servidor apenas se abre el programa. Con las dos, la PC se reinicia y el stream vuelve solo.
Hay una tercera opción que conviene conocer: detener el stream si la señal está ausente por cierto tiempo (el nivel de detección por defecto es -50 dB). Parece absurdo cortar tu propio stream a propósito. Pero piensa en la automatización que se cuelga y saca silencio a las tres de la mañana. Con el fallback configurado, BUTT se detiene, Icecast pasa a los oyentes al archivo de respaldo, y cuando el audio vuelve, la opción de iniciar con señal presente reconecta. El silencio al aire se convierte en una identificación de la emisora. Solo no pongas un tiempo demasiado corto, o una pausa dramática del locutor manda a todos al respaldo.
El Windows del estudio se reinicia cuando quiere
Aquí vive la caída que más aparece de madrugada. Windows instala actualizaciones y reinicia fuera de lo que llama "horas activas". Según Microsoft, el valor por defecto en PCs es de 8 a 17 horas, y las versiones actuales aceptan como máximo 18 horas activas.
Haz la cuenta: radio al aire 24 horas, máximo de 18 horas activas. Quedan 6 horas al día en las que Windows puede reiniciar la máquina del encoder. Y si nadie tocó el valor por defecto, son 15.
Se ajusta en Inicio > Configuración > Windows Update > Opciones avanzadas > Horas activas, como muestra la página de soporte de Microsoft. Elige el modo manual y cubre tus horas de mayor audiencia. Para muchas radios, el horario fuerte es la mañana, y un reinicio a las 9 es lo peor que puede pasar. Pero cambiar el horario no alcanza: el reinicio va a ocurrir en algún momento, y lo que te salva es el ajuste anterior, el encoder que vuelve solo.
La prueba que yo haría esta semana
En una madrugada de poca audiencia, con el fallback ya configurado, reinicia a propósito la computadora del encoder y escucha desde el celular, con datos móviles, como te escucha tu audiencia. Toma el tiempo. ¿Entró el audio de respaldo? ¿La señal en vivo volvió sin que tocaras el teclado? ¿Cuánto tardó?
Si algo falló, lo descubriste un martes a las 3 de la mañana, y no en medio de la transmisión que pagó un anunciante. Después repite la prueba desconectando el cable de red por un minuto. Son diez minutos de trabajo, y la próxima caída va a ser solo una identificación al aire.
Foto de portada: estudio de Radio Maria en Adliswil, Suiza. Radio Maria, CC BY-SA 4.0, vía Wikimedia Commons.
