¿Qué es AES67?

Definición y contexto de las revisiones

AES67 se titula oficialmente AES standard for audio applications of networks - High-performance streaming audio-over-IP interoperability (estándar AES para aplicaciones de audio en redes: interoperabilidad de audio de alto rendimiento en transmisión sobre IP). La Audio Engineering Society publicó la primera edición en 2013 y emitió la revisión AES67-2018 después de que la experiencia de la industria pusiera de relieve ambigüedades y detalles de integración que necesitaban un tratamiento más claro.

El estándar no crea un único ecosistema cerrado. Define un punto de encuentro técnico donde productos de distintos fabricantes pueden intercambiar audio en tiempo real cuando cada producto implementa el perfil requerido y el integrador de sistemas configura correctamente la red compartida. El cumplimiento es, por tanto, un punto de partida, no una promesa de que toda función opcional o de gestión vaya a funcionar automáticamente.

Para trabajos de adquisición y diseño, cite la edición utilizada y verifique la declaración de conformidad del fabricante. AES67-2018 es la revisión a la que hacen referencia la mayoría de los documentos de adquisición actuales, pero los equipos deben comprobar igualmente en el catálogo de estándares de la AES si existen enmiendas, correcciones o ediciones posteriores antes de congelar una especificación.

El estándar define la interoperabilidad en capas seleccionadas. No estandariza todos los comportamientos operativos que ve el usuario.

El problema de interoperabilidad que AES67 resuelve

Antes de AES67, cada plataforma de audio sobre IP resolvía problemas similares a su manera. Una red Dante, una red RAVENNA, un sistema Livewire o una instalación Q-LAN podía entregar audio en tiempo real excelente dentro de su propia familia de productos, pero el enrutamiento directo entre fabricantes a menudo requería puentes, hardware de conversión o soluciones manuales improvisadas.

Esa fragmentación creaba riesgo comercial y operativo. Una instalación podía volverse dependiente de un solo ecosistema para el enrutamiento, el reloj, el control y el soporte. Ampliar el sistema obligaba a comprobar la compatibilidad de protocolos antes de evaluar la acústica, el flujo de trabajo o el precio. El equipamiento heredado resultaba más difícil de conservar cuando llegaba una nueva plataforma.

AES67 aborda ese problema al especificar una vía común de interoperabilidad para el transporte de audio. Permite que un ecosistema nativo exponga flujos seleccionados en una forma que otro ecosistema capaz de AES67 puede recibir. Por eso se suele describir AES67 como un puente: no borra las diferencias entre plataformas, pero hace posible un movimiento controlado entre ellas.

Fundamentos del audio sobre IP

Un sistema AoIP convierte el audio muestreado en paquetes con marca de tiempo, envía esos paquetes a través de infraestructura Ethernet e IP y reconstruye una señal de audio continua en el receptor. La parte difícil no es mover bytes, sino preservar el tiempo de muestreo, la relación entre canales y la continuidad de reproducción mientras se comparte una red de paquetes con otro tráfico.

AES67 asume una red administrada capaz de separar los medios en tiempo real de los datos ordinarios. Los conmutadores necesitan almacenamiento en búfer suficiente, control de multidifusión y priorización de tráfico. Los enrutadores pueden llevar flujos entre subredes cuando el diseño admite enrutamiento de multidifusión o flujos de unidifusión, pero cada frontera añade requisitos de configuración y supervisión.

El reloj de medios es independiente del reloj de paquetes. PTP alinea el tiempo de los dispositivos, mientras que la tasa de muestreo del audio define el reloj de medios. Un receptor debe recuperar tanto la fase de muestreo correcta como un flujo estable de muestras. La pérdida de paquetes, el jitter excesivo o un reloj inestable pueden producir cortes aunque el ancho de banda medio de la red sea más que suficiente.

Trate el diseño de red como parte del sistema de audio, no como infraestructura de apoyo. Las VLAN, la QoS, los dominios PTP, los queriers de multidifusión y las políticas de almacenamiento en búfer de los conmutadores deben validarse en conjunto. Para rutas de programa críticas también deben definirse el modo degradado, la ruta de alarmas y el tiempo de recuperación tras un fallo.

• El muestreo convierte el audio analógico en valores numéricos discretos a una velocidad definida.
• La paquetización añade información de secuencia, marca de tiempo y carga útil para que los receptores puedan reconstruir el flujo.
• El almacenamiento en búfer absorbe la variación normal de la red, pero aumenta la latencia de extremo a extremo.
• La sincronización mantiene dispositivos independientes alineados con una misma referencia de tiempo compartida.

PTPv2, RTP y SDP

AES67 utiliza el IEEE 1588-2008 Precision Time Protocol, comúnmente llamado PTPv2, para distribuir una referencia de tiempo común. Los mensajes PTP permiten a los dispositivos comparar marcas de tiempo y corregir el retardo de red. En los sistemas de audio, la base de tiempo resultante permite a emisores y receptores colocar las muestras en una línea de tiempo compartida en lugar de depender únicamente de la frecuencia del oscilador local.

El Real-time Transport Protocol, definido en el RFC 3550, transporta la carga de audio. RTP aporta números de secuencia y marcas de tiempo que permiten a los receptores detectar paquetes perdidos o desordenados y reconstruir el tiempo de reproducción previsto. El RTP Control Protocol puede proporcionar estadísticas de recepción, aunque las opciones de control y supervisión varían según el producto.

El Session Description Protocol describe el flujo antes de recibirlo. Un documento SDP identifica el tipo de medio, la dirección, el puerto, el formato de carga útil, el tiempo de paquete, el mapeo de canales y otros parámetros. En algunos sistemas el SDP se intercambia directamente; en otros lo transporta una capa de descubrimiento o de gestión. Como AES67 no define un protocolo universal de control de dispositivos, el manejo del SDP puede diferir entre implementaciones.

PTP, RTP y SDP son estándares utilizados por AES67. No son etiquetas de marketing opcionales.

QoS, PCM y comportamiento de multidifusión

AES67 utiliza audio PCM lineal para que los receptores no necesiten un códec propietario para interoperar. Las formas comunes de carga útil son PCM de 16 bits y de 24 bits, a menudo descritas por tipos de carga RTP como L16 y L24. Un emisor y un receptor deben acordar la tasa de muestreo, el tiempo de paquete, el tipo de carga útil, el número de canales y el orden de los canales.

La calidad de servicio (QoS) importa porque los paquetes de audio son sensibles al retardo aunque no necesariamente tengan un ancho de banda alto. Los marcados DSCP y el tratamiento de colas dan prioridad al tráfico PTP y RTP frente a las transferencias de archivos, las copias de seguridad y los datos generales de oficina. Una VLAN puede ayudar a separar el tráfico de medios, pero la separación en VLAN no sustituye por sí sola a un diseño y una supervisión adecuados de las colas.

La multidifusión permite que un emisor distribuya un flujo a varios receptores sin duplicar el tráfico por cada punto final. También introduce riesgos: un snooping IGMP mal configurado, queriers ausentes o una inundación accidental pueden alterar toda la red. Los despliegues grandes deben planificar los rangos de direcciones de multidifusión, la ubicación de los queriers, los límites de grupos y los dominios PTP antes de la puesta en marcha.

Después de la puesta en producción, la pérdida de paquetes, el jitter, el desplazamiento PTP, el estado IGMP y las colas de los conmutadores requieren observación continua. Muchos problemas de interoperabilidad no se manifiestan como silencio absoluto, sino como cortes intermitentes, canales izquierdo y derecho intercambiados, fallos de recuperación tras un reinicio o anomalías que solo aparecen con mayor carga. La observabilidad debe diseñarse junto con la ruta de audio.

• Reserve capacidad y presupuestos de cola para el tráfico de medios.
• Utilice un plan de direcciones de multidifusión documentado.
• Verifique el dominio PTP y los ajustes de prioridad en todos los conmutadores.
• Supervise la pérdida de paquetes, el jitter, los desplazamientos de reloj y el estado IGMP tras el despliegue.

Lo que AES67 no define

AES67 no prescribe un único sistema automático de descubrimiento de dispositivos. Algunos productos usan anuncios SAP, otros usan mDNS o Bonjour, y otros dependen de un controlador nativo o de una herramienta de orquestación de terceros. Un dispositivo puede ser compatible con AES67 y aun así requerir intercambio manual de SDP o software del fabricante para establecer una conexión.

Tampoco define un modelo universal de gestión de conexiones, una interfaz de usuario obligatoria o una arquitectura de seguridad completa. Los permisos de enrutamiento, las convenciones de nomenclatura, las actualizaciones de firmware, el control de acceso y las API de supervisión siguen siendo específicos del producto. Esta es una de las razones por las que la interoperabilidad AES67 suele funcionar mejor cuando un controlador o una capa de gestión por encima del transporte de audio pueden coordinar los puntos finales.

La redundancia es otra frontera importante. AES67 define las capas de transmisión y sincronización, no la duplicación de paquetes ni la conmutación sin interrupciones. Los sistemas que requieren redundancia sin cortes habitualmente añaden un esquema de redundancia de red procedente de la arquitectura circundante, como enlaces duales con un método de protección específico para medios, y el comportamiento exacto depende de los productos y del diseño de red.

Por último, AES67 no garantiza interoperabilidad por el mero hecho de que un distintivo aparezca en una ficha técnica. La implementación sigue teniendo que negociar parámetros compatibles, admitir el formato de carga requerido y comportarse correctamente bajo las condiciones PTP y de red previstas.

Interoperabilidad entre Dante, RAVENNA y AES67

Dante es la tecnología propietaria de audio en red de Audinate. La interoperabilidad Dante AES67 suele aparecer como un modo o configuración que permite a flujos Dante seleccionados intercambiar audio con otros dispositivos AES67. El descubrimiento, el enrutamiento, el control y la gestión nativos de Dante siguen formando parte del ecosistema Dante, de modo que una conexión AES67 puede coexistir con un plano de control que aún requiere Dante Controller u otra herramienta de Audinate.

RAVENNA es una plataforma tecnológica abierta construida en torno a protocolos IP estándar y estrechamente alineada con AES67 y SMPTE ST 2110-30. Puede transportar perfiles, formatos, números de canales, opciones de sincronización y modelos de redundancia adicionales más allá del contrato mínimo de interoperabilidad AES67. AES67 es, por tanto, una capa común dentro de un despliegue RAVENNA más amplio, no una descripción completa de todas las capacidades de RAVENNA.

Los diseños híbridos son habituales. Una instalación puede conservar un parque Dante nativo para cajas de escenario, amplificadores y consolas mientras usa AES67 para conectar un núcleo de radiodifusión, un sistema de producción RAVENNA o un procesador específico de terceros. El plan de integración debe identificar qué puntos finales son nativos, cuáles están en modo de interoperabilidad, dónde se intercambia el SDP y quién es responsable de la política de reloj y de multidifusión.

La parte más frágil suele ser no ya si el audio puede enviarse, sino cómo se mantiene la frontera. Si ambos lados vuelven a conectarse tras una actualización de firmware, un reinicio de dispositivo, una conmutación del reloj maestro o un fallo de red; si las alarmas llegan a un único lugar; y si existe un procedimiento de mantenimiento claro: todo ello debe definirse en las primeras fases del proyecto.

El modo de interoperabilidad es una decisión de diseño del sistema. No borra las diferencias entre las funciones nativas.

Orientación para el despliegue

Comience con un plan por escrito de señales y reloj. Enumere cada flujo, su dirección, tasa de muestreo, tiempo de paquete, número de canales, grupo de multidifusión, dirección de origen, receptor y ruta de respaldo. Decida si la red usará unidifusión o multidifusión para cada clase de tráfico y defina cómo se transmitirá y almacenará el SDP.

Construya un plan de dominio PTP antes de añadir puntos finales. Confirme qué dispositivos pueden ser grandmasters, cómo se tratan los boundary clocks o transparent clocks, qué ocurre si desaparece el grandmaster preferido y si la red cuenta con una estrategia de holdover estable. Pruebe el rendimiento PTP con la misma configuración de conmutadores y la misma carga de tráfico previstas en operación.

Después pruebe la interoperabilidad como sistema, no como demostración de producto. Confirme el mapeo de canales, la ganancia nominal, la alineación de muestras, la recuperación de los flujos tras un evento de enlace, el comportamiento de unión y salida de multidifusión y la visibilidad de gestión. Incluya casos límite como discrepancias de firmware, un grandmaster reiniciado, un receptor desconectado y un enlace ascendente congestionado.

La puesta en marcha debe dejar evidencia duradera: configuraciones de conmutadores, registros PTP, registros de flujos, resultados de pruebas y responsables de los cambios futuros. AES67 simplifica el contrato de transporte, pero no elimina la necesidad de disciplina profesional de red.

Las soluciones de módulos AES67 de SoundNet

Entender el estándar es una cosa; que un producto hable AES67 de forma fiable es otra. Los módulos OEM de la serie YW de SoundNet reúnen una implementación AES67 completa y probada en producción — reloj PTPv2, transporte de audio RTP y descubrimiento de dispositivos — en hardware integrable. Los fabricantes de audio profesional pueden añadir audio en red a sus productos sin construir la pila desde cero. La familia va del compacto YW04d 4×4 al módulo Mini-PCI YWRG128 con hasta 128×128 canales a 48, 96 o 192 kHz.

Alrededor de los módulos opera una cadena de herramientas que cubre todo el flujo de trabajo: el AES67 LINK Controller sin licencia para enrutado y configuración, la AES67 Virtual Soundcard que convierte un PC en un endpoint 64×64, el AES67 Panel alimentado por PoE para el control de sala y el Stream Monitor de código abierto para verificar flujos multicast en una red real.

• Pila AES67 completa en el módulo: la sincronización, el transporte y el descubrimiento los gestiona el módulo, no tu equipo de firmware
• Escalable de 4×4 a 128×128 canales mediante interfaces I2S/TDM a 48/96/192 kHz
• DSP opcional a bordo: EQ paramétrica, filtros, delay, puerta de ruido y supresión de realimentación
• Un único esfuerzo de integración para toda la familia, desde endpoints pequeños hasta transporte de alta densidad
• Herramientas para el producto final: LINK Controller, VSC, Panel y Stream Monitor cubren configuración, enrutado y monitorización

Aplicaciones y errores comunes

AES67 se usa en instalaciones de radiodifusión, lugares de culto, centros de convenciones, estadios, salas de espectáculos, estudios de grabación e instalaciones extensas de campus. Resulta especialmente útil donde equipos de varios fabricantes deben compartir audio, donde un parque AoIP existente debe conectarse a un nuevo núcleo de producción, o donde se exige un transporte basado en estándares por mantenibilidad a largo plazo.

Un error común es pensar que AES67 significa que todo dispositivo AES67 puede controlarse de la misma manera. En la práctica, el audio puede fluir mientras el descubrimiento, el enrutamiento, las etiquetas y la supervisión siguen separados. Otro error es considerar AES67 un nivel de calidad o un códec. Es un marco de interoperabilidad; la calidad de audio depende de la fuente, el formato de muestra, el reloj y el comportamiento de la red.

Un tercer error es suponer que AES67 y ST 2110-30 son nombres intercambiables del mismo estándar. Están estrechamente relacionados, pero AES67 es un estándar de interoperabilidad de audio de la AES, mientras que ST 2110-30 es un componente de audio restringido del conjunto más amplio de SMPTE para medios profesionales sobre IP. Algunos documentos técnicos escriben ST2110 sin espacio al nombrar la familia. La distinción importa al especificar flujos de trabajo de radiodifusión, control NMOS, perfiles PTP y niveles de conformidad.

Por último, AES67 no es un botón que resuelva automáticamente toda cuestión de compatibilidad. El alcance del soporte del producto, las opciones disponibles, las licencias, el estado del firmware, el diseño de red y los procedimientos operativos influyen en el resultado. Documentar los límites con claridad y ejecutar pruebas de aceptación de extremo a extremo es más fiable que confiar en distintivos o afirmaciones de marketing.