Read in English.

Perspectiva histórica y evolución del streaming:

A finales de los años 90, la web se centraba principalmente en el intercambio de texto como información útil para la comunidad. Algunos sitios nacieron con fines comerciales o publicitarios y otros por la pura pasión de compartir conocimiento, pero desde entonces, la multimedia ha sido mi verdadera fascinación. Recuerdo perfectamente los inicios de los años 2000, cuando mis artistas favoritos empezaron a subir los videoclips de sus conciertos; esperábamos minutos de buffering para ver apenas unos segundos de vídeo, convencidos de que estábamos ante una tecnología de vanguardia. En aquel entonces, ya soñábamos con un futuro en el que apagaríamos nuestras televisiones para empezar a verlo todo por internet.

Poco después la mejora en las velocidades de banda ancha transformó la experiencia pero los primeros intentos de transmitir vídeo en vivo fueron realmente especiales para la historia del streaming. Remontándonos a 1994 The Rolling Stones realizó su primera transmisión musical en directo por internet lo que supone uno de los hitos tecnológicos más importantes de la red. Aunque solo se transmitieron los primeros 20 minutos del concierto ver un vídeo en directo a apenas 10 cuadros por segundo y en blanco y negro marcó la historia a pesar de que solo pudieron conectarse unas 200 personas por las limitaciones de la época. De hecho otra banda formada por ingenieros llamada Severe Tire Damage tocó justo antes que los Stones aprovechando la misma infraestructura. Esta historia siempre me ha parecido fascinante y me inspiró a intentar construir mi propia aplicación para transmitir audio y vídeo en directo sabiendo perfectamente que aunque hoy existan mil soluciones disponibles el reto de crear una propia sigue teniendo ese algo especial.

Artículo sobre la primera transmisión en directo por internet de The Rolling Stones (en inglés).

Si bien en los años 90, desde el punto de vista de un usuario más de internet, la tecnología de streaming en directo y bajo demanda parecía viable y maduraba con el tiempo, la realidad es que todavía no era algo masivo y estaba llena de fallos. El problema principal era que la escalabilidad era un terreno que los primeros entusiastas de la tecnología no tenían en cuenta. Sin embargo, cuando internet comenzó a masificarse y la banda ancha empezó a soportar un mayor flujo de información, las aplicaciones web ganaron alcance y el problema de la escalabilidad explotó. Ya no solo había que enfocarse en que la aplicación cumpliera su objetivo, como transmitir vídeo, sino también en gestionar la enorme cantidad de usuarios que podrían conectarse simultáneamente y los recursos que debían ponerse a disposición de la red.

Aparecieron retos críticos como las diferencias de calidad entre las conexiones de los usuarios y, sobre todo, la gestión del retardo o latencia, que puede arruinar la experiencia, especialmente si hay un chat grupal en la transmisión donde el desfase impide que la interacción se sienta fluida. Para que una tecnología de streaming funcione de verdad, necesita una infraestructura compleja con elementos como redundancias para evitar caídas, redes de entrega de contenido (CDN) para distribuir la carga, y servidores especializados en la transmisión de flujos de datos. También es fundamental la gestión de paquetes, el control de ACKs (confirmaciones de recepción) para asegurar que la información llega íntegra, y el análisis constante de estadísticas de uso y errores para saber con precisión si la transmisión fue correcta o si la aplicación está fallando.

Conforme pasó el tiempo, por ejemplo, a mediados de los años 2000, y los desarrolladores empezaron a incorporar en diferentes grados las tecnologías de streaming, aparecieron emprendedores que trabajaban en frentes muy distintos. Surgieron aplicaciones de vídeo bajo demanda, audio bajo demanda y videoconferencia, entre otras, pero algunos se centraron en estudiar las posibilidades de entrelazar transmisiones en directo simultáneas. Esto es algo que no resulta prioritario en las aplicaciones de streaming convencionales, pero es vital si intentamos ayudar a que los músicos ensayen conjuntamente piezas de música a través de internet. Este último caso me pareció un terreno fascinante para investigar, aunque era totalmente consciente de que es un problema muy sofisticado de resolver. Aquí entra en juego un tipo de streaming que exige condiciones técnicas extremas, que permitan retroalimentar a los usuarios transmisores en un rango no superior a los 30 milisegundos de retardo. Ese es el límite crítico de latencia que los músicos pueden tolerar para que una ejecución conjunta sea viable al tocar mediante internet y ser transmitida a su público.

Lo cierto es que yo estudié música en mi infancia y tenía colegas con los que, con el tiempo, dejé de tocar por la dificultad de encontrar momentos comunes o por las complicaciones de trasladarnos a una sala de ensayo, algo casi imposible entre estudios, trabajo y responsabilidades. Recuerdo que hacer música con otros, o interpretar piezas ensayadas, es un verdadero deleite, y mucho más si esa música se comparte en vivo con un público. Si todo sale bien, se logra una conexión humana que lleva siglos desarrollándose, desde los virtuosos de la música clásica hasta los grandes espectáculos de la Beatlemanía. La música es un vínculo humano muy especial y, ante el avance de internet y las técnicas de streaming, parecía posible recrear esa experiencia en un entorno virtual. Lo cierto es que es posible, pero requiere matices técnicos importantes. He tenido que explorar caminos distintos para lograr una experiencia fluida, priorizando una arquitectura inteligente sobre la fuerza bruta del hardware. El resultado es Plaudere, donde he logrado hacer viable, al menos en parte, esa conexión musical remota que tanto buscaba.

El desafío técnico de la latencia:

El desafío principal al conectar intérpretes ubicados en distintas localizaciones radica en la latencia inherente, es decir, el retardo acumulado entre los dispositivos de captura, el procesamiento del servidor y la recepción final por parte de la audiencia. Para que una interacción musical sea natural, el retardo total debe mantenerse estrictamente por debajo de los 30 milisegundos. En la década de 2010, alcanzar esta cifra requería hardware de alta gama y servidores ultrapotentes, una infraestructura costosa e inaccesible para la mayoría. Tras probar personalmente numerosos servicios con colegas músicos para intentar realizar ensayos de música a distancia, comprobé que la tecnología de aquel entonces sencillamente no lo permitía.

Incluso hoy, en la era del cloud computing, mantener este estándar de forma estable sigue siendo un reto complejo, especialmente cuando la aplicación debe combinar múltiples flujos de datos en una única transmisión. Esta barrera técnica no es solo una cuestión de ancho de banda, sino de gestionar el retardo que introduce cada nodo de la red, desde la captura hasta la distribución. Por esta razón, durante la pandemia decidí abordar el problema desde una perspectiva diferente, buscando una arquitectura más eficiente que eliminara la dependencia de infraestructuras prohibitivas. Fue en ese proceso de búsqueda donde logré hallazgos técnicos interesantes que hoy, finalmente, comparto a través de Plaudere.

Distancia física frente a distancia digital:

En una ejecución musical en vivo, si el guitarrista y el cantante se separan por más de 12 o 15 metros, la velocidad del sonido genera un desfase superior a los 30 milisegundos, rompiendo la sincronía natural. En un escenario, esto se soluciona mediante monitores de audio que transmiten la señal electrónicamente, permitiendo que ambos perciban la ejecución de forma instantánea. Sin embargo, cuando la distancia física es tal que impide una conexión electrónica directa, debemos apoyarnos en la infraestructura de internet para tender un puente entre los músicos y permitirles seguir creando música juntos. En este escenario, la red deja de ser un simple canal de datos y se convierte en el entorno donde debemos luchar contra el tiempo para preservar la sincronía de la ejecución. Aunque la fibra óptica permite una transmisión a gran velocidad, el trayecto a través de múltiples routers, los buffers de los dispositivos y las interfaces de audio introduce un retardo acumulado que desincroniza el flujo de datos.

Es aquí donde el modelo de streaming convencional falla. Intentar emular la inmediatez física mediante hardware de coste prohibitivo no es la solución definitiva, ya que el problema persiste debido a la arquitectura de red y la gestión de paquetes. Tras analizar profundamente este fenómeno, llegué a la conclusión de que intentar forzar la física con más potencia bruta era un camino erróneo. En lugar de eso, era necesario adoptar un enfoque de ingeniería de software más creativo, capaz de optimizar la cadena de transmisión desde el origen hasta el destino sin depender de equipos extremadamente sofisticados.

Un enfoque costo-eficiente para el vivo:

Muchos vínculos musicales se rompen debido a la distancia geográfica y las responsabilidades de la vida adulta, lo que hace casi imposible encontrar tiempo para ensayar o mantener esa conexión mágica del pasado. A principios de la década de 2010, realicé un experimento para desafiar esta limitación: pedí a un colega que me llamara por teléfono para cantar su parte de una canción mientras yo, escuchándolo a través del terminal, tocaba la guitarra en vivo frente a un micrófono. Mi micrófono capturaba ambas fuentes, su voz filtrada por el teléfono y mi guitarra acústica, y las enviaba a un servicio de streaming convencional. Quienes nos escuchaban quedaron sorprendida por la coordinación lograda desde ubicaciones distintas, lo que sembró en mí una obsesión técnica: crear un servicio que permitiera esta colaboración sin depender de llamadas externas, auriculares o hardware adicional.

A principios de 2020, impulsado por la necesidad de retomar estas transmisiones conjuntas, decidí construir un prototipo. Al no tener experiencia previa en desarrollo de aplicaciones nativas para móviles o escritorio, aposté por el desarrollo web. Es una tecnología universal, totalmente compatible con cualquier dispositivo y accesible mediante un navegador sin necesidad de instalaciones ni actualizaciones constantes. Aunque el desarrollo web no era mi dominio inicial, el aprendizaje de los fundamentos de HTML, CSS y JavaScript me permitió avanzar con rapidez hacia la lógica del servidor y las bases de datos, buscando siempre un enfoque que fuera costo eficiente pero técnicamente sólido.

Con el objetivo de agilizar el ciclo de desarrollo y mantener un stack coherente, decidí utilizar Node.js en el backend para unificar el lenguaje de desarrollo en todo el stack, permitiéndome gestionar tanto el frontend como el backend con JavaScript. Implementé MongoDB para la persistencia de datos y creé múltiples prototipos para analizar los pros y contras del procesamiento en el lado del servidor frente al cliente. Para la arquitectura de la aplicación, utilicé APIs de alto rendimiento que se convirtieron en la columna vertebral de mi solución: la Web Audio API para el procesamiento de señales, la Media Recorder API para la captura de fragmentos de audio y vídeo, y WebSockets para garantizar una comunicación bidireccional instantánea.

Experimentación con flujos de audio:

Mi primer experimento técnico consistió en un enfoque tipo walkie-talkie utilizando la Media Recorder API. La aplicación capturaba un mensaje de audio, lo enviaba al servidor y lo distribuía a un consumidor mediante WebSockets. A partir de ahí, exploré la transmisión continua mediante el envío de fragmentos o chunks de duración fija para ser reproducidos en orden. El reto principal fue gestionar la continuidad ante fluctuaciones de ancho de banda o pérdidas de conexión, asegurando que la aplicación respondiera dinámicamente para mostrar siempre el contenido más reciente al oyente, incluso tras una interrupción.

Una vez lograda una transmisión estable que superaba las restricciones del navegador, como la necesidad de una interacción del usuario para iniciar el audio, retomé el problema de combinar dos intérpretes. Como la escucha mutua en tiempo real sigue siendo un ideal difícil de alcanzar por la latencia, opté por un enfoque más eficiente y menos complejo: un flujo de audio unidireccional. En este modelo, el audio viaja del primer músico al segundo, y es en el nodo de este último donde ambas señales se combinan para la transmisión final.

Debido a la naturaleza de esta solución, el audio fluye sin retroalimentación hacia el primer intérprete. Para mantener la cohesión musical, el primer streamer utiliza una pista de referencia o backing track que simula lo que el segundo ejecutará. De este modo, el primer músico reacciona en vivo a una grabación, y el segundo reacciona en vivo al flujo del primero. Esta arquitectura permite corregir errores de ejecución en tiempo real y garantiza que ambas fuentes se integren perfectamente para la audiencia, pudiendo enriquecerse además con archivos de karaoke, pistas u otras fuentes externas.

Sin embargo, al combinar flujos mediante las APIs de Media Recorder y Web Audio, pueden surgir desincronizaciones en la mezcla final. Para mitigar esto, es fundamental parametrizar un retardo que sincronice las múltiples fuentes. Afortunadamente, la Web Audio API permite implementar nodos de retardo programables para alinear una señal con otra. Dado que medir el retardo exacto de forma automática es sumamente complejo, esta solución permite ajustar la sincronía de forma manual en las opciones del servicio, logrando un equilibrio preciso entre simplicidad técnica y calidad artística.

Implementación de video adaptativo:

Tras consolidar el audio, exploré las transmisiones audiovisuales, donde el vídeo presenta desafíos críticos de ancho de banda. Si un fragmento de vídeo se pierde durante la transmisión, la sesión puede volverse inestable y desincronizarse. Para resolver esto, en lugar de grabar fragmentos de vídeo, opté por capturar instantáneas o snapshots (un array de imágenes) de forma sincronizada con la grabación del audio. Esta técnica permite un rendimiento adaptativo, donde la calidad de la imagen y la tasa de cuadros por segundo se ajustan dinámicamente mediante el uso de un canvas. Si la conexión se debilita, la aplicación reduce la frecuencia de imágenes para priorizar siempre la integridad y continuidad del audio.

Actualmente, la aplicación gestiona la calidad de forma global para equilibrar la carga del servidor, aunque esto presenta retos importantes. Una de las limitaciones actuales es que el modelo no prioriza a ningún usuario, sin importar su orden de entrada en la transmisión ni si se trata de los propios intérpretes, lo que significa que la entrada de nuevos espectadores puede degradar la calidad de la señal para todos los participantes. Optimizar este balance de carga y garantizar la estabilidad de los intérpretes frente a la audiencia es uno de mis objetivos prioritarios para el futuro de Plaudere. He comprobado que el camino hacia una colaboración artística real en internet no depende de la fuerza bruta del hardware, sino de una arquitectura capaz de adaptarse a las limitaciones humanas y tecnológicas de nuestra red actual.

Conclusiones y potencial estratégico:

Esta solución técnica abarca desde transmisiones individuales, donde las señales de los dispositivos se combinan con contenido pregrabado, hasta la colaboración dual. En Plaudere, el servidor se utiliza para almacenar y distribuir fragmentos o chunks de datos, descartando cuadros de imagen si es necesario para priorizar siempre el tiempo real y el menor retardo posible. Mediante operaciones ejecutadas en el lado del cliente, la aplicación logra adaptarse a las restricciones de la red, permitiendo que el flujo del primer intérprete viaje hacia el segundo para ser integrados en una única señal coherente para la audiencia.

La implementación de este esfuerzo tecnológico en Plaudere multiplica las posibilidades de expresión para los usuarios. Ya seas un músico buscando esa conexión perdida o un escritor compartiendo su proceso creativo, la plataforma permite invitar a un colega y generar la ilusión de estar en el mismo espacio físico. Actualmente, seguimos optimizando el desarrollo para que el uso de la red refleje estrictamente lo necesario, garantizando una transmisión estable y accesible. Al final, Plaudere es el resultado de entender que la tecnología no debe ser una barrera, sino el puente que nos permite recuperar la magia de crear juntos, sin importar la distancia.