O que é AES67?

Definição e contexto de revisão

O AES67 tem como título oficial AES standard for audio applications of networks - High-performance streaming audio-over-IP interoperability. A Audio Engineering Society publicou a primeira edição em 2013 e emitiu a revisão AES67-2018 depois que a experiência da indústria revelou ambiguidades e detalhes de integração que exigiam um tratamento mais claro.

O padrão não cria um único ecossistema fechado. Ele define um ponto de encontro técnico em que produtos de diferentes fabricantes podem trocar áudio em tempo real quando cada produto implementa o perfil exigido e o integrador de sistemas configura corretamente a rede compartilhada. A conformidade é, portanto, um ponto de partida, não uma promessa de que todo recurso opcional ou função de gerenciamento funcionará automaticamente.

Para trabalhos de aquisição e projeto, cite a edição utilizada e verifique a declaração de conformidade do fabricante. O AES67-2018 é a revisão mencionada pela maioria dos documentos de aquisição atuais, mas as equipes ainda devem consultar o catálogo de padrões da AES em busca de emendas, erratas ou edições posteriores antes de congelar uma especificação.

O padrão define a interoperabilidade em camadas selecionadas. Ele não padroniza todos os comportamentos operacionais que um usuário vê.

O problema de interoperabilidade que o AES67 resolve

Antes do AES67, cada plataforma de áudio sobre IP resolvia problemas semelhantes à sua própria maneira. Uma rede Dante, uma rede RAVENNA, um sistema Livewire ou uma instalação Q-LAN podia entregar excelente áudio em tempo real dentro de sua própria família de produtos, mas o roteamento direto entre fabricantes muitas vezes exigia pontes, hardware de conversão ou soluções alternativas manuais.

Essa fragmentação criava risco comercial e operacional. Uma instalação podia ficar dependente de um único ecossistema para roteamento, clocking, controle e suporte. Expandir o sistema significava verificar a compatibilidade de protocolos antes de avaliar acústica, fluxo de trabalho ou preço. Equipamentos legados ficavam mais difíceis de manter quando uma nova plataforma chegava.

O AES67 resolve esse problema ao especificar um caminho comum de interoperabilidade para o transporte de áudio. Ele permite que um ecossistema nativo exponha fluxos selecionados em uma forma que outro ecossistema com capacidade AES67 possa receber. É por isso que o AES67 é frequentemente descrito como uma ponte: ele não apaga as diferenças entre plataformas, mas torna possível o trânsito controlado entre elas.

Fundamentos do áudio sobre IP

Um sistema AoIP converte áudio amostrado em pacotes com marcação de tempo, envia esses pacotes por infraestrutura Ethernet e IP e reconstrói um sinal de áudio contínuo no receptor. A parte difícil não é mover bytes. É preservar o tempo de amostragem, a relação entre canais e a continuidade de reprodução enquanto se compartilha uma rede de pacotes com outros tráfegos.

O AES67 pressupõe uma rede gerenciada, capaz de separar mídia em tempo real de dados comuns. Os switches precisam de buffer suficiente, controle de multicast e priorização de tráfego. Os roteadores podem levar fluxos entre sub-redes quando o projeto dá suporte a roteamento multicast ou fluxos unicast, mas cada fronteira adiciona requisitos de configuração e monitoramento.

O clock de mídia é separado do clock de pacotes. O PTP alinha o tempo dos dispositivos, enquanto a taxa de amostragem do áudio define o clock de mídia. Um receptor deve recuperar tanto a fase de amostragem correta quanto um fluxo estável de amostras. Perda de pacotes, jitter excessivo ou um clock instável podem produzir cortes mesmo quando a largura de banda média da rede é mais do que suficiente.

Trate o projeto da rede como parte do sistema de áudio, e não como infraestrutura de apoio. VLANs, QoS, domínios PTP, queriers de multicast e políticas de buffer dos switches precisam ser validados em conjunto. Para caminhos críticos de programa, você também deve definir o modo degradado, o caminho de alarmes e o tempo de recuperação após uma falha.

• A amostragem converte o áudio analógico em valores numéricos discretos a uma taxa definida.
• O empacotamento adiciona informações de sequência, marcação de tempo e payload para que os receptores possam reconstruir o fluxo.
• O buffer absorve a variação normal da rede, mas aumenta a latência de ponta a ponta.
• A sincronização mantém dispositivos independentes alinhados a uma mesma referência de tempo compartilhada.

PTPv2, RTP e SDP

O AES67 usa o IEEE 1588-2008 Precision Time Protocol, comumente chamado de PTPv2, para distribuir uma referência de tempo comum. As mensagens PTP permitem que os dispositivos comparem marcações de tempo e corrijam o atraso da rede. Em sistemas de áudio, a base de tempo resultante permite que transmissores e receptores coloquem as amostras em uma linha do tempo compartilhada, em vez de depender apenas da frequência do oscilador local.

O Real-time Transport Protocol, definido na RFC 3550, carrega o payload de áudio. O RTP fornece números de sequência e marcações de tempo que permitem aos receptores detectar pacotes perdidos ou fora de ordem e reconstruir o instante de reprodução pretendido. O RTP Control Protocol pode fornecer estatísticas de recepção, embora as escolhas de controle e monitoramento variem de produto para produto.

O Session Description Protocol descreve o fluxo antes de ele ser recebido. Um documento SDP identifica o tipo de mídia, o endereço, a porta, o formato do payload, o tempo de pacote, o mapeamento de canais e outros parâmetros. Em alguns sistemas, o SDP é trocado diretamente; em outros, ele é carregado por uma camada de descoberta ou gerenciamento. Como o AES67 não define um protocolo universal de controle de dispositivos, o tratamento do SDP pode variar entre implementações.

PTP, RTP e SDP são padrões usados pelo AES67. Eles não são selos de marketing opcionais.

Comportamento de QoS, PCM e multicast

O AES67 usa áudio PCM linear para que os receptores não precisem de um codec proprietário para interoperar. As formas comuns de payload são PCM de 16 bits e 24 bits, frequentemente descritas por tipos de payload RTP como L16 e L24. Transmissor e receptor devem concordar quanto à taxa de amostragem, ao tempo de pacote, ao tipo de payload, ao número de canais e à ordenação de canais.

A Qualidade de Serviço (QoS) é importante porque os pacotes de áudio são sensíveis a atraso, mas não necessariamente intensivos em largura de banda. Marcações DSCP e o tratamento de filas dão prioridade ao tráfego PTP e RTP sobre transferências de arquivos, backups e dados gerais de escritório. Uma VLAN pode ajudar a separar o tráfego de mídia, mas a separação por VLAN, por si só, não substitui um projeto adequado de filas e o monitoramento correspondente.

O multicast permite que um transmissor distribua um fluxo para vários receptores sem duplicar o tráfego para cada ponto final. Ele também introduz riscos: IGMP snooping mal configurado, queriers ausentes ou inundação acidental podem desestabilizar toda a rede. Implantações grandes devem planejar faixas de endereços multicast, posicionamento de queriers, limites de grupos e domínios PTP antes do comissionamento.

Após a entrada em operação, perda de pacotes, jitter, desvio PTP, estado IGMP e filas dos switches exigem observação contínua. Muitos problemas de interoperabilidade não aparecem como silêncio completo, mas como cortes intermitentes, canais esquerdo e direito trocados, falha de recuperação após uma reinicialização ou anomalias que só surgem sob carga maior. A observabilidade deve ser projetada junto com o caminho de áudio.

• Reserve capacidade e orçamentos de fila para o tráfego de mídia.
• Use um plano de endereços multicast documentado.
• Verifique as configurações de domínio e prioridade PTP em todos os switches.
• Monitore perda de pacotes, jitter, desvios de clock e estado IGMP após a implantação.

O que o AES67 não define

O AES67 não prescreve um único sistema automático de descoberta de dispositivos. Alguns produtos usam anúncios SAP, alguns usam mDNS ou Bonjour e alguns dependem de um controlador nativo ou de uma ferramenta de orquestração de terceiros. Um dispositivo pode ter capacidade AES67 e ainda assim exigir troca manual de SDP ou software do fabricante para estabelecer uma conexão.

Ele também não define um modelo universal de gerenciamento de conexões, uma interface de usuário obrigatória ou uma arquitetura de segurança completa. Permissões de roteamento, convenções de nomenclatura, atualizações de firmware, controle de acesso e APIs de monitoramento permanecem específicos do produto. Este é um dos motivos pelos quais a interoperabilidade AES67 muitas vezes funciona melhor quando um controlador ou uma camada de gerenciamento acima do transporte de áudio pode coordenar os pontos finais.

A redundância é outra fronteira importante. O AES67 define as camadas de streaming e sincronização, não a duplicação de pacotes sem interrupção nem a comutação automática. Sistemas que exigem redundância hitless normalmente adicionam um esquema de redundância de rede vindo da arquitetura ao redor, como enlaces duplos com um método de proteção específico para mídia, e o comportamento exato depende dos produtos e do projeto de rede.

Por fim, o AES67 não garante interoperabilidade apenas porque um selo aparece em uma ficha técnica. A implementação ainda precisa negociar parâmetros compatíveis, dar suporte ao formato de payload exigido e comportar-se corretamente nas condições de PTP e de rede esperadas.

Interoperabilidade entre Dante, RAVENNA e AES67

Dante é a tecnologia proprietária de rede de áudio da Audinate. A interoperabilidade Dante AES67 normalmente aparece como um modo ou configuração que permite que fluxos Dante selecionados troquem áudio com outros dispositivos AES67. A descoberta, o roteamento, o controle e o gerenciamento nativos do Dante permanecem parte do ecossistema Dante, de modo que uma conexão AES67 pode coexistir com um plano de controle que ainda exige o Dante Controller ou outra ferramenta da Audinate.

RAVENNA é uma plataforma tecnológica aberta construída em torno de protocolos IP padrão e fortemente alinhada ao AES67 e ao SMPTE ST 2110-30. Ela pode carregar perfis, formatos, contagens de canais, opções de sincronização e modelos de redundância adicionais além do contrato mínimo de interoperabilidade do AES67. O AES67 é, portanto, uma camada comum dentro de uma implantação RAVENNA mais ampla, e não uma descrição completa de cada recurso da RAVENNA.

Projetos híbridos são comuns. Uma instalação pode manter um parque Dante nativo para stage boxes, amplificadores e mesas de som enquanto usa o AES67 para conectar um núcleo de broadcast, um sistema de produção RAVENNA ou um processador específico de terceiros. O plano de integração deve identificar quais pontos finais são nativos, quais estão em modo de interoperabilidade, onde o SDP é trocado e quem é responsável pela política de clock e multicast.

A parte mais frágil muitas vezes não é se o áudio pode ser enviado, mas como a fronteira é mantida. Se ambos os lados reconectam após uma atualização de firmware, uma reinicialização de dispositivo, uma comutação de clock mestre ou uma falha de rede; se os alarmes chegam a um único lugar; e se existe um procedimento de manutenção claro — tudo isso precisa ser definido no início do projeto.

O modo de interoperabilidade é uma decisão de projeto de sistema. Ele não apaga as diferenças entre recursos nativos.

Orientações de implantação

Comece com um plano escrito de sinais e clocks. Liste cada fluxo, sua direção, taxa de amostragem, tempo de pacote, número de canais, grupo multicast, endereço de origem, receptor e caminho de contingência. Decida se a rede usará unicast ou multicast para cada classe de tráfego e defina como o SDP será transmitido e armazenado.

Monte um plano de domínio PTP antes de adicionar pontos finais. Confirme quais dispositivos podem ser grandmasters, como boundary clocks e transparent clocks são tratados, o que acontece se o grandmaster preferido desaparecer e se a rede tem uma estratégia de holdover estável. Teste o desempenho do PTP com a mesma configuração de switches e a mesma carga de tráfego esperadas em operação.

Em seguida, teste a interoperabilidade como um sistema, e não como uma demonstração de produto. Confirme o mapeamento de canais, o ganho nominal, o alinhamento de amostras, a recuperação de fluxo após um evento de enlace, o comportamento de entrada e saída de grupos multicast e a visibilidade de gerenciamento. Inclua casos extremos como divergência de firmware, um grandmaster reinicializado, um receptor desconectado e um uplink congestionado.

O comissionamento deve deixar evidências duradouras: configurações de switches, logs PTP, registros de fluxos, resultados de testes e responsabilidade por mudanças futuras. O AES67 simplifica o contrato de transporte, mas não elimina a necessidade de disciplina profissional de rede.

As soluções de módulos AES67 da SoundNet

Compreender o padrão é uma coisa; fazer um produto falar AES67 de forma confiável é outra. Os módulos OEM da série YW da SoundNet reúnem uma implementação AES67 completa e comprovada em produção — clock PTPv2, transporte de áudio RTP e descoberta de dispositivos — em hardware embarcável. Os fabricantes de áudio profissional podem assim adicionar áudio em rede aos seus produtos sem construir a pilha do zero. A família vai do compacto YW04d 4×4 ao módulo Mini-PCI YWRG128 com até 128×128 canais a 48, 96 ou 192 kHz.

Em volta dos módulos opera uma cadeia de ferramentas que cobre todo o fluxo de trabalho: o AES67 LINK Controller sem licença para roteamento e configuração, a AES67 Virtual Soundcard que transforma um PC num endpoint 64×64, o AES67 Panel alimentado por PoE para controle de sala e o Stream Monitor de código aberto para verificar fluxos multicast numa rede real.

• Pilha AES67 completa no módulo: sincronização, transporte e descoberta ficam a cargo do módulo, não da sua equipe de firmware
• Escalável de 4×4 a 128×128 canais em interfaces I2S/TDM a 48/96/192 kHz
• DSP opcional a bordo: EQ paramétrico, filtros, delay, noise gate e supressão de feedback
• Um único esforço de integração para toda a família, de pequenos endpoints ao transporte de alta densidade
• Ferramentas para o produto final: LINK Controller, VSC, Panel e Stream Monitor cobrem configuração, roteamento e monitoramento

Aplicações e equívocos comuns

O AES67 é usado em instalações de broadcast, casas de culto, centros de conferências, estádios, casas de espetáculo, estúdios de gravação e grandes instalações de campus. Ele é especialmente útil onde equipamentos de vários fabricantes precisam compartilhar áudio, onde um parque AoIP existente deve se conectar a um novo núcleo de produção ou onde um transporte baseado em padrões é exigido para manutenibilidade em longo prazo.

Um equívoco é que AES67 signifique que todo dispositivo AES67 pode ser controlado da mesma maneira. Na prática, o áudio pode fluir enquanto descoberta, roteamento, rótulos e monitoramento permanecem separados. Outro equívoco é que o AES67 seja um nível de qualidade ou um codec. Ele é uma estrutura de interoperabilidade; a qualidade do áudio depende da fonte, do formato de amostra, do clocking e do comportamento da rede.

Um terceiro equívoco é que AES67 e ST 2110-30 sejam nomes intercambiáveis do mesmo padrão. Eles estão intimamente relacionados, mas o AES67 é um padrão de interoperabilidade de áudio da AES, enquanto o ST 2110-30 é um componente de áudio restrito do conjunto mais amplo de mídia profissional sobre IP da SMPTE. Alguns documentos técnicos escrevem ST2110 sem o espaço ao citar a família. A distinção importa ao especificar fluxos de trabalho de broadcast, controle NMOS, perfis PTP e níveis de conformidade.

Por fim, o AES67 não é um botão que resolve automaticamente toda questão de compatibilidade. O escopo de suporte do produto, as opções disponíveis, o licenciamento, o estado do firmware, o projeto de rede e os procedimentos operacionais influenciam o resultado. Documentar os limites com clareza e executar testes de aceitação de ponta a ponta é mais confiável do que depender de selos ou afirmações de marketing.