AES67 es un estándar técnico para la interoperabilidad de audio sobre IP y audio sobre Ethernet (AoE). El estándar fue desarrollado por Audio Engineering Society y publicado por primera vez en septiembre de 2013. Es un conjunto de protocolos de capa 3 basado en estándares existentes y está diseñado para permitir la interoperabilidad entre varios sistemas de redes de audio basados en IP como RAVENNA , Livewire , Q-LAN y Dante .
AES67 | |
---|---|
Información del fabricante | |
Fabricante | Sociedad de Ingeniería de Audio |
Fecha de desarrollo | Septiembre de 2013 [1] |
Compatibilidad de red | |
Conmutable | sí |
Enrutable | sí |
Velocidades de datos de Ethernet | Fast Ethernet , Gigabit Ethernet , 5GBASE-T , 10 Gigabit Ethernet |
Especificaciones de audio | |
Latencia mínima | 125 μs hasta 4 ms |
Máximo de canales por enlace | 120 |
Máxima velocidad de muestreo | 48, 44,1 o 96 kHz [1] |
Profundidad máxima de bits | 16 o 24 bits [1] |
AES67 promete interoperabilidad entre sistemas de audio en red que competían anteriormente [2] e interoperación de red a largo plazo entre sistemas. [3] También proporciona interoperabilidad con tecnologías de capa 2, como Audio Video Bridging (AVB) . [4] [5] [6] Desde su publicación, AES67 ha sido implementado de forma independiente por varios fabricantes y adoptado por muchos otros.
Descripción general
AES67 define los requisitos para sincronizar relojes, establecer prioridades de QoS para el tráfico de medios e iniciar transmisiones de medios con protocolos estándar del conjunto de protocolos de Internet . AES67 también define el formato de muestra de audio y la frecuencia de muestreo, el número de canales admitidos, así como el tamaño del paquete de datos IP y los requisitos de latencia / almacenamiento en búfer.
El estándar menciona varias opciones de protocolo para el descubrimiento de dispositivos, pero no requiere que se implemente ninguna. El protocolo de inicio de sesión se utiliza para la gestión de conexiones de unidifusión. No se define ningún protocolo de gestión de conexiones para conexiones de multidifusión.
Sincronización
AES67 utiliza el protocolo de tiempo de precisión IEEE 1588-2008 (PTPv2) para la sincronización del reloj. Para equipos de red estándar, AES67 define parámetros de configuración para un "perfil PTP para aplicaciones de medios", basado en la sincronización de solicitud-respuesta de retardo IEEE 1588 y (opcionalmente) sincronización entre pares (IEEE 1588 Anexos J.3 y J4); Los mensajes de eventos se encapsulan en paquetes IPv4 sobre transporte UDP (IEEE 1588 Anexo D). Algunos de los parámetros predeterminados se ajustan, específicamente, logSyncInterval y logMinDelayReqInterval se reducen para mejorar la precisión y el tiempo de inicio. El grado de reloj 2, como se define en la señal de referencia de audio digital AES11 (DARS), se indica con clockClass.
Los equipos de red que cumplen con IEEE 1588-2008 utilizan perfiles PTP predeterminados; para transmisiones de video, se puede utilizar el perfil PTP SMPTE 2059-2 .
En las redes AVB / TSN, la sincronización se logra con el perfil IEEE 802.1AS para aplicaciones sensibles al tiempo.
El reloj de medios se basa en la hora de la red sincronizada con una época IEEE 1588 (1 de enero de 1970 00:00:00 TAI). Las frecuencias de reloj se fijan en frecuencias de muestreo de audio de 44,1 kHz, 48 kHz y 96 kHz (es decir, miles de muestras por segundo). El transporte RTP funciona con un desplazamiento de tiempo fijo al reloj de la red.
Transporte
Los datos de los medios se transportan en paquetes IPv4 e intenta evitar la fragmentación de IP .
El protocolo de transporte en tiempo real con perfil RTP para audio y video (formatos L24 y L16) se utiliza sobre el transporte UDP. La carga útil RTP está limitada a 1460 bytes, para evitar la fragmentación con la MTU Ethernet predeterminada de 1500 bytes (después de restar la sobrecarga IP / UDP / RTP de 20 + 8 + 12 = 40 bytes). [7] Los identificadores de fuente contribuyente (CSRC) y el cifrado TLS no son compatibles.
Los protocolos de sincronización de tiempo, entrega de flujo de medios y descubrimiento pueden usar multidifusión IP con negociación IGMPv 2 (opcionalmente IGMPv3). A cada flujo de medios se le asigna una dirección de multidifusión única (en el rango de 239.0.0.0 a 239.255.255.255); solo un dispositivo puede enviar a esta dirección (no se admiten conexiones de varios a varios).
Para supervisar mantenimiento de conexión de estado y asignar ancho de banda, los dispositivos pueden utilizar RTCP intervalo de informe, temporizadores de sesión SIP y de ping OPCIONES, o solicitud de eco ICMP (ping).
AES67 utiliza DiffServ para establecer las prioridades de tráfico de QoS en el campo Punto de código de servicios diferenciados (DSCP) del paquete IP. Se deben admitir tres clases como mínimo:
Nombre de la clase | Tipo de trafico | Clase DiffServ predeterminada (valor decimal DSCP) |
---|---|---|
Reloj | Eventos de tiempo IEEE 1588-2008 * | EF (46) |
Medios de comunicación | Flujos de medios RTP / RTCP | AF41 (34) |
Mejor esfuerzo | Gestión de señalización, descubrimiento y conexión IEEE 1588-2008 | DF (0) |
- Announce, Sync, Follow_Up, Delay_Req, Delay_Resp, Pdelay_Req, Pdelay_Resp, Pdelay_Resp_Follow_Up
Es posible que se requiera un retardo máximo de 250 μs para aplicaciones de tiempo crítico para evitar caídas de audio. Para priorizar los flujos de medios críticos en una red grande, las aplicaciones pueden usar valores adicionales en la clase 4 de reenvío asegurado con baja probabilidad de caída (AF41), generalmente implementada como una cola de operación por turnos ponderada. El tráfico de reloj se asigna a la clase Expedited Forwarding (EF), que normalmente implementa un comportamiento de prioridad estricta por salto (PHB). Todo el resto del tráfico se gestiona de la mejor manera posible con el reenvío predeterminado.
El procedimiento de señalización de fuente de reloj RTP se utiliza para especificar el dominio PTP y la ID de gran maestro para cada flujo de medios.
Codificación de audio
Los formatos de muestra incluyen PCM lineal de 16 y 24 bits con una frecuencia de muestreo de 48 kHz y opcionalmente de 24 bits a 96 kHz y 16 bits a 44,1 kHz. Es posible que se admitan otros formatos de audio y video RTP . Las frecuencias de muestreo múltiples son opcionales. Los dispositivos pueden imponer un ajuste de frecuencia de muestreo global.
Los paquetes de medios se programan de acuerdo con el "tiempo del paquete": la duración de la transmisión de un paquete Ethernet estándar. La fuente de transmisión negocia el tiempo del paquete para cada sesión de transmisión. Los tiempos de paquete cortos proporcionan baja latencia y alta velocidad de transmisión, pero introducen una sobrecarga alta y requieren equipos y enlaces de alto rendimiento. Los tiempos de paquetes prolongados aumentan las latencias y requieren más almacenamiento en búfer. Se define un rango de 125 μs a 4 ms, aunque se recomienda que los dispositivos se adapten a los cambios de tiempo de paquete y / o determinen el tiempo de paquete mediante el análisis de marcas de tiempo RTP.
El tiempo del paquete determina el tamaño de la carga útil RTP de acuerdo con una frecuencia de muestreo admitida. Se requiere 1 ms para todos los dispositivos. Los dispositivos deben admitir un mínimo de 1 a 8 canales por transmisión. [7]
Tiempo de paquete | Muestras por paquete | Notas | |
---|---|---|---|
48 / 44,1 kHz | 96 kHz | ||
125 μs | 6 | 12 | Compatible con AVB Clase A |
250 μs | 12 | 24 | Operación de baja latencia de alto rendimiento. Compatible con AVB Clase B, interoperable con AVB Clase A |
333+1 ⁄ 3 μs | dieciséis | 32 | Operación eficiente de baja latencia |
1 ms | 48 | 96 | Tiempo de paquete requerido para todos los dispositivos |
4 ms | 192 | 384 | Redes de área amplia, redes con capacidades QoS limitadas o interoperabilidad con EBU 3326 |
- Las restricciones de tamaño de MTU limitan un flujo de audio de 96 kHz usando un tiempo de paquete de 4 ms a un solo canal.
Formato de audio | Tiempo de paquete | ||||
---|---|---|---|---|---|
125 μs | 250 μs | 333+1 ⁄ 3 μs | 1 ms | 4 ms | |
48 kHz de 16 bits | 120 | 60 | 45 | 15 | 3 |
24 bits 48 kHz | 80 | 40 | 30 | 10 | 2 |
24 bits, 96 kHz | 40 | 20 | 15 | 5 | 1 |
Latencia
La latencia de la red ( desplazamiento de enlace ) es la diferencia de tiempo entre el momento en que un flujo de audio entra en la fuente (tiempo de entrada), marcado por la marca de tiempo RTP en el paquete de medios, y el momento en que sale del destino (tiempo de salida). La latencia depende del tiempo del paquete, la propagación y los retrasos en la cola, la sobrecarga de procesamiento de paquetes y el almacenamiento en búfer en el dispositivo de destino; por lo tanto, la latencia mínima es el tiempo de paquete y el tiempo de reenvío de red más cortos, que puede ser inferior a 1 μs en un enlace Gigabit Ethernet punto a punto con un tamaño de paquete mínimo, pero en las redes del mundo real podría ser el doble del tiempo de paquete.
Los búferes pequeños reducen la latencia, pero pueden provocar caídas de audio cuando los datos multimedia no llegan a tiempo. Los cambios inesperados en las condiciones de la red y la fluctuación de la codificación y el procesamiento de paquetes pueden requerir un almacenamiento en búfer más prolongado y, por lo tanto, una mayor latencia. Se requiere que los destinos utilicen un búfer de 3 veces el tiempo del paquete, aunque se recomienda al menos 20 veces el tiempo del paquete (o 20 ms si es menor). Se requiere que las fuentes mantengan la transmisión con un jitter de menos de 17 paquetes de tiempo (o 17 ms si es más corto), aunque se recomienda 1 paquete de tiempo (o 1 ms si es más corto).
Interoperabilidad con AVB
AES67 puede transportar flujos de medios como IEEE 802.1BA AVB de tráfico sensible al tiempo Clases A y B en redes compatibles, con latencia garantizada de 2 ms y 50 ms respectivamente. La reserva de ancho de banda con Stream Reservation Protocol (SRP) especifica la cantidad de tráfico generado a través de un intervalo de medición de 125 μs y 250 μs respectivamente. Las direcciones IP de multidifusión deben usarse, aunque solo con una única fuente, ya que las redes AVB solo admiten el direccionamiento de destino de multidifusión Ethernet en el rango de 01: 00: 5e: 00: 00: 00 a 01: 00: 5e: 7f: ff: ff.
Un mensaje de anuncio de hablante SRP se mapeará de la siguiente manera:
StreamID | Un ID único global de 64 bits ( dirección MAC Ethernet de 48 bits de la fuente e ID de flujo de fuente único de 16 bits). |
---|---|
Dirección de destino de la transmisión | Dirección de destino de multidifusión Ethernet. |
ID de VLAN | Etiqueta VLAN IEEE 802.1Q de 12 bits. El identificador de VLAN predeterminado para transmisiones AVB es 2. |
MaxFrameSize | El tamaño máximo de los paquetes de flujo de medios, incluido el encabezado IP, pero excluyendo la sobrecarga de Ethernet. |
MaxIntervalFrames | Número máximo de tramas que una fuente puede transmitir en un intervalo de medición. Dado que los tiempos de paquete permitidos son mayores (o iguales) que los intervalos de medición de AVB, siempre es 1. |
Prioridad del marco de datos | 3 para la clase A, 2 para la clase B. |
Rango | 1 para tráfico normal, 0 para tráfico de emergencia. |
Tanto en IEEE 1588-2008 como en IEEE 802.1AS, un reloj PTP puede designarse como reloj ordinario (OC), reloj de límite (BC) o reloj transparente (TC), aunque los relojes transparentes 802.1AS también tienen algunas capacidades de reloj de límite. Un dispositivo puede implementar una o más de estas capacidades. OC puede tener tan solo un puerto (conexión de red), mientras que TC y BC deben tener dos o más puertos. Los puertos BC y OC pueden funcionar como maestro (gran maestro) o esclavo. Se asocia un perfil IEEE 1588 con cada puerto. TC puede pertenecer a múltiples dominios y perfiles de reloj. Estas disposiciones hacen posible sincronizar los relojes IEEE 802.1AS con los relojes IEEE 1588-2008 utilizados por AES67.
Historia de desarrollo
El estándar fue desarrollado por la Audio Engineering Society a partir de finales de 2010. [8] El estándar se publicó inicialmente en septiembre de 2013. [9] [10] [11] [12] Una segunda impresión que agregó una declaración de patente de Audinate fue publicado en marzo de 2014.
La Media Networking Alliance se formó en octubre de 2014 para promover la adopción de AES67. [13]
En octubre de 2014 se llevó a cabo un plugfest para probar la interoperabilidad lograda con AES67. [14] [15] Se llevó a cabo un segundo plugfest en noviembre de 2015 [16] y el tercero en febrero de 2017. [17]
En septiembre de 2015 se publicó una actualización de la norma que incluye aclaraciones y correcciones de errores. [1]
En mayo de 2016, AES publicó un informe que describe la interoperabilidad de sincronización entre AES67 y SMPTE 2059-2 . [18]
En junio de 2016, el transporte de audio AES67 mejorado por la sincronización del reloj AVB / TSN y la reserva de ancho de banda se demostró en InfoComm 2016. [19]
En septiembre de 2017, SMPTE publicó ST 2110, un estándar para video profesional sobre IP . [20] ST 2110-30 utiliza AES67 como transporte de audio que acompaña al vídeo. [21]
En diciembre de 2017, Media Networking Alliance se fusionó con Alliance for IP Media Solutions (AIMS) combinando esfuerzos para promover el transporte de red basado en estándares para audio y video. [22]
En abril de 2018 se publicó AES67-2018. El principal cambio en esta revisión es la adición de una declaración de conformidad de implementación de protocolo (PICS). [23]
El Comité de Estándares AES y el editor de AES67, Kevin Gross, recibieron un premio Emmy de Tecnología e Ingeniería en 2019 por el desarrollo de transporte de audio sin comprimir multicanal sincronizado a través de redes IP. [24]
Adopción
El estándar ha sido implementado por Lawo , [25] Axia , [26] AMX (en dispositivos SVSI), Wheatstone, [27] [28] Extron Electronics , Riedel, [29] Ross Video , [30] [31] ALC NetworX , [32] Audinate , [33] [34] [35] [36] [37] [38] Archwave, [39] Digigram, [40] Sonifex, [41] Yamaha , [42] QSC , [43] Neutrik , Attero Tech, [44] Merging Technologies, [45] [46] Gallery SIENNA, [47] y es compatible con dispositivos habilitados para RAVENNA bajo su perfil operativo AES67. [48]
Productos de envío
Con el tiempo, esta tabla crecerá hasta convertirse en un recurso de integración y compatibilidad entre dispositivos. Los métodos de descubrimiento admitidos por cada dispositivo son fundamentales para la integración, ya que la especificación AES67 no estipula cómo debe hacerse, sino que proporciona una variedad de opciones o sugerencias. Además, AES67 especifica multidifusión o unidifusión, pero muchos dispositivos AES67 solo admiten multidifusión.
Vendedor | Producto | Descripción | Plataforma OS | Modelo AES67 | Enviar | Recibir | Multidifusión | Unidifusión | Notas |
---|---|---|---|---|---|---|---|---|---|
Fusionar tecnologías | Dispositivo de audio virtual [49] | Controladores Ravenna / AES67 | macOS, [50] Linux, [51] Windows | Rávena AES67 | SAP, mDNS / RTSP | SAP, mDNS / RTSP | Y | Y | Libre |
Redes ALC | Tarjeta de sonido virtual [52] | Controlador Ravenna / AES67 WDM | Ventanas | Rávena AES67 | Y | Libre | |||
Redes ALC | RAV2SAP [53] | Herramientas de descubrimiento AES67 | Ventanas | Rávena AES67 | SAVIA | mDNS / RTSP | Y | Libre | |
Tierra de siena | Puerta de enlace AES67 a NDI [47] | Puerta de enlace AES67 a NDI | macOS, Linux, Windows | Nativo AES67 | SAVIA | SAVIA | Y | norte | |
Tierra de siena | NDI a AES67 [54] | Remitente NDI a AES67 | macOS, Linux | Nativo AES67 | SAVIA | SAVIA | Y | norte | |
Lawo | VRX4 [55] | Mezclador de audio | Ventanas | Rávena AES67 | Y | ||||
Hasseb | AdE [56] | Interfaz AES67 analógica y óptica | Nativo AES67 | mDNS / RTSP | mDNS / RTSP | Y | Y | ||
QSC | DSP, amplificadores [57] | varios | Q-SYS AES67 | SAVIA | SAVIA | Y | |||
AXIA | Varios [58] | varios | Livewire + AES67 | Y | Y | ||||
Yamaha | Mezcladores [59] | varios | Dante AES67 | SAVIA | SAVIA | Y | norte | ||
Attero Tech | Puntos finales [60] | Puntos finales | Attero AES67 | SAVIA | SAVIA | Y | norte | ||
Entretenimiento SoundTube | Varios [61] | Varios | Dante AES67 |
Referencias
- ^ a b c d "AES67-2013: estándar AES para aplicaciones de audio de redes - Interoperabilidad de transmisión de audio sobre IP de alto rendimiento" . Sociedad de Ingeniería de Audio . 2013-09-11 . Consultado el 11 de febrero de 2014 .
- ^ Steve Harvey (27 de junio de 2014). "Revisión del producto NAB Show: Audio" . Tecnología de TV . Archivado desde el original el 3 de marzo de 2016 . Consultado el 29 de junio de 2014 .
- ^ Dave Davies (22 de julio de 2014). "Mark Yonge sobre el nuevo amanecer de la creación de redes" . Instalación. Archivado desde el original el 28 de julio de 2014 . Consultado el 23 de julio de 2014 . Cite journal requiere
|journal=
( ayuda ) - ^ AES67-2018 - Anexo C (Informativo) - Transporte de red AVB
- ^ AES67-2018 - Anexo D (informativo) - Interfaz con dominios de reloj IEEE 802.1AS
- ^ Nestor Amaya (marzo de 2016). "AES67 para la producción de audio: antecedentes, aplicaciones y desafíos" (PDF) .
- ^ a b AES67-101: Conceptos básicos de AES67 . Anthony P. Kuzub
- ^ Iniciación AES-X192 , Audio Engineering Society , 2010-12-01
- ^ Dan Daley (octubre de 2013). "AES lanza un nuevo estándar de redes de audio al anillo" . Consultado el 11 de febrero de 2014 .
- ^ Dan Daley (16 de septiembre de 2013). "AES anuncia el estándar de interoperabilidad de audio sobre IP en red AES67-2013" . Consultado el 11 de febrero de 2014 . Cite journal requiere
|journal=
( ayuda ) - ^ "AES anuncia nuevo estándar de interoperabilidad de audio sobre IP en red: AES67-2013" . ProSoundWeb. 2013-09-12 . Consultado el 11 de febrero de 2014 .
- ^ "AES anuncia nuevo estándar de interoperabilidad de audio sobre IP en red: AES67-2013" . Radio. 2013-09-16. Archivado desde el original el 17 de febrero de 2017 . Consultado el 11 de febrero de 2014 . Cite journal requiere
|journal=
( ayuda ) - ^ "AES Show presenta Media Networking Alliance" . Radio World . 2014-10-06. Archivado desde el original el 24 de septiembre de 2015 . Consultado el 11 de noviembre de 2014 .
- ^ Jon Chapple (27 de noviembre de 2014), "AES Standards Committee, EBU test AES67 at PlugFest" , PSN Europe , archivado desde el original el 4 de diciembre de 2014 , consultado el 29 de noviembre de 2014
- ^ AES-R12-2014: Informe del proyecto de estándares - AES67 Interoperability PlugFest - Munich 2014 , Audio Engineering Society , 2014-11-24
- ^ AES-R15-2015: Informe del proyecto de estándares - AES67 Interoperability PlugFest - Washington 2015 , Audio Engineering Society , 2016-01-02
- ^ AES-R17-2017: Informe del proyecto de estándares - AES67 Interoperability PlugFest - Londres 2017 , Audio Engineering Society , 2017-04-28
- ^ AES-R16-2016: Informe de estándares AES: parámetros PTP para la interoperabilidad AES67 y SMPTE ST 2059-2 , Audio Engineering Society , 2016-05-02
- ^ Joao Martins (16 de junio de 2016). "AVB / TSN Momentum y AES67 / AVB Harmony en InfoComm 2016" . Consultado el 8 de diciembre de 2016 .
- ^ "SMPTE aprueba los estándares ST 2110-30 para medios profesionales sobre redes IP administradas" . Consultado el 30 de noviembre de 2017 .
- ^ Leigh Whitcomb (30 de junio de 2017), "Audio para televisión: cómo encajan AES67 y el video sin comprimir 2022/2110 / TR03", SMPTE Motion Imaging Journal , SMPTE, 126 (5): 35–40, doi : 10.5594 / JMI.2017.2703479
- ^ Michelle Clancy (28 de diciembre de 2017), AIMS, fusión de Media Networking Alliance , Rapid TV News
- ^ "AES67-2018: estándar AES para aplicaciones de audio de redes - Publicado interoperabilidad de audio sobre IP en streaming de alto rendimiento" . 2018-04-24.
- ^ https://theemmys.tv/tech-71st-award-recipients/
- ^ Lawo. "Lawo apoya la exitosa demostración de interoperabilidad AES67 durante la Convención AES en Nueva York" . www.lawo.com . Consultado el 26 de octubre de 2017 .
- ^ "Axia anuncia el primer producto de transmisión con cumplimiento de AES67" . Sonido e imagen. 2013-11-14 . Consultado el 11 de febrero de 2014 . Cite journal requiere
|journal=
( ayuda ) - ^ "IP Audio da un gran paso adelante" . Radio World . 2014-02-21. Archivado desde el original el 24 de septiembre de 2015 . Consultado el 18 de junio de 2014 .
- ^ Steve Harvey (11 de agosto de 2014). "La estandarización de AoIP permite la interoperabilidad" . Tecnología de TV . Archivado desde el original el 13 de agosto de 2014 . Consultado el 13 de agosto de 2014 .
- ^ "Reidel causará sensación en SATIS 2014" . Producción digital . 29 de octubre de 2014 . Consultado el 11 de noviembre de 2014 .
- ^ http://coveloz.com/bach
- ^ "Coveloz Bach: primer punto final AES67 del mundo en obtener la certificación AVnu ' " . Pro-Audio Central. 6 de enero de 2016 . Consultado el 6 de febrero de 2016 .
- ^ "ALC NetworX muestra Ravenna, AES67" . Radio World . 2014-01-29. Archivado desde el original el 24 de septiembre de 2015 . Consultado el 11 de febrero de 2014 .
- ^ "Estándares" . Audinate .
- ^ "Audinate anuncia soporte para el estándar AES67" . Red de foros de sonido. 2014-02-04. Archivado desde el original el 22 de febrero de 2014 . Consultado el 11 de febrero de 2014 .
- ^ "Audinate anuncia soporte para el estándar AES67" . Pro Audio Central. 2014-02-04. Archivado desde el original el 21 de febrero de 2014 . Consultado el 11 de febrero de 2014 .
- ^ "Dante para agregar transporte AES67" . Noticias de ProSound. 2014-02-05. Archivado desde el original el 27 de septiembre de 2015 . Consultado el 11 de febrero de 2014 . Cite journal requiere
|journal=
( ayuda ) - ^ Michael Williams (8 de abril de 2015), Audinate anuncia la disponibilidad de una actualización de firmware para admitir AES67 , rAVe
- ^ Jon Chapple (11 de febrero de 2015). "ISE 2015: los módulos de red AES67 de Archwave proporcionan 'MIDI 3.0 con esteroides ' " . PSN Europa. Archivado desde el original el 16 de abril de 2015 . Consultado el 2 de mayo de 2015 .
- ^ "Digigrama para mostrar la compatibilidad RAVENNA / AES67 de la línea de códec de audio IP IQOYA en IBC2014" . IABM. 2014-08-05. Archivado desde el original el 8 de agosto de 2014 . Consultado el 5 de agosto de 2014 .
- ^ "Copia archivada" . Archivado desde el original el 7 de febrero de 2016 . Consultado el 17 de mayo de 2016 .CS1 maint: copia archivada como título ( enlace )
- ^ Productos Yamaha Dante compatibles con AES67 , ProSoundWeb, 9 de septiembre de 2016
- ^ "Versión del software de la plataforma QSC Q-SYS para admitir AES67" . QSC . 7 de diciembre de 2016.
- ^ Attero Tech Ships AES67 Networked Audio Products , consultado el 17 de diciembre de 2017
- ^ Merging Technologies-Digigram Aneman , consultado el 20 de febrero de 2018
- ^ ISE 2017: RAVENNA presenta el rack de demostración AES67 , consultado el 20 de febrero de 2018
- ^ a b "AES67" . www.sienna-tv.com .
- ^ "RAVENNA & AES67" . ALC NetworX. Archivado desde el original el 21 de febrero de 2014 . Consultado el 12 de febrero de 2014 .
- ^ Tecnologías, Fusión. "Fusionar tecnologías | Horus y Hapi Mic-Pre y AD / DA para DAW de terceros" . www.merging.com .
- ^ Tecnologías, Fusión. "Fusionar tecnologías | Audio en red | Estándar AES67 VAD" . www.merging.com .
- ^ Tecnologías, Fusión. "Combinación de tecnologías | Controlador de Linux ALSA RAVENNA AES67" . www.merging.com .
- ^ "¡La versión gratuita de la tarjeta de sonido virtual RAVENNA para Windows ya está disponible para descargar!" . Red de medios basada en IP RAVENNA . 13 de septiembre de 2013.
- ^ "Convertidor de gestión de conexión RAVENNA-2-SAP AES67" . Red de medios basada en IP RAVENNA .
- ^ "Procesador NDIP" . www.sienna-tv.com .
- ^ "Software mezclador de radio virtual VRX4" .
- ^ "Audio Over Ethernet Pro" . hasseb.fi .
- ^ "Núcleos Q-SYS - Productos, periféricos y accesorios - Ecosistema Q-SYS - Productos - Sistemas - QSC" . www.qsc.com .
- ^ "Conexión en red Livewire + AES67 AoIP" . www.telosalliance.com .
- ^ "Conexión de dispositivos Yamaha Dante con otros dispositivos AES67" . Yamaha.
- ^ "Guía de inicio rápido de redes de audio AES67" . www.atterotech.com .
- ^ "Serie" . Soundtube Entertainment . Consultado el 11 de abril de 2019 .
enlaces externos
- Alianza de redes de medios
- Alianza AIMS
- Patrick Killiany (octubre de 2016). Introducción a AES67 . Sistemas de audio comerciales de Yamaha.
- Implementación de código abierto AES67 (propuesta)
- Recepción de una transmisión AES67 con GStreamer , Collabora, 25 de abril de 2017