O que é AES67 e por que isso importa para profissionais de áudio

Na indústria profissional de áudio, a mudança da analógica para a digital trouxe notável fidelidade e flexibilidade, mas com ela surgiu um novo desafio: interoperabilidade. Diferentes fabricantes desenvolveram suas próprias soluções de áudio-over-IP (AoIP), criando ecossistemas isolados que não poderiam se comunicar entre si. A AES67 foi desenvolvida para quebrar essas barreiras. Este padrão aberto, lançado pela Audio Engineering Society em 2013, define um conjunto comum de protocolos e mecanismos de transporte que permitem que qualquer dispositivo compatível com AES67 descubra, conecte e transmita áudio com qualquer outro dispositivo AES67 – independentemente do fornecedor. Para profissionais de áudio que trabalham em som ao vivo, transmissão, estúdios de gravação ou instalados, a compreensão de som AES67 é essencial para a construção de redes flexíveis, econômicas e à prova de custos.

Este artigo fornece um olhar aprofundado para AES67, seus fundamentos técnicos, dicas de implementação prática e como se compara com outros padrões populares de AOIP.

Antes da AES67, o áudio sobre IP era uma paisagem fragmentada. Dante, Ravenna, AVB, LiveWire e Q-LAN cada um tinha seus próprios mecanismos de transporte, métodos de sincronização e protocolos de descoberta. tradutor universal, definindo um perfil mínimo comum que qualquer fornecedor poderia implementar. Não substituiu os sistemas existentes, mas sim uma ponte entre eles. Hoje, AES67 é amplamente adotado e forma a base para normas de IP de transmissão como SMPTE ST 2110.

O objetivo central da AES67

AES67, formalmente conhecido como Padrão AES para aplicações de áudio de redes – Interoperabilidade áudio-over-IP de streaming de alto desempenho, não é um protocolo de rede completo por si só. Em vez disso, especifica um conjunto de requisitos que os protocolos existentes devem cumprir para garantir a interoperabilidade. O padrão se concentra em três áreas-chave: transporte, sincronização e descoberta de fluxos. Ao mandar perfis comuns para RTP (Real-time Transport Protocol), PTP (Precision Time Protocol) e SAP (Session Advertiment Protocol), AES67 garante que os dispositivos de diferentes fabricantes podem trocar fluxos de áudio de alta qualidade e baixa latência sem gateways proprietários.

O padrão suporta até 2 canais por fluxo em sua implementação de base, mas vários fluxos podem ser combinados para suportar contagens de canais mais altas. Ele opera em redes Ethernet padrão usando IPv4 ou IPv6, tornando-o acessível na infraestrutura de TI existente. As taxas de amostragem de 48 kHz e 96 kHz são suportadas com profundidades de bits de 16, 20 ou 24 bits. A latência é configurável, mas normalmente varia de 1 milissegundo a vários milissegundos, adequado para a maioria das aplicações profissionais.

Um aspecto crucial é que o AES67 não dita uma topologia de rede específica ou os requisitos de switch. Em vez disso, define parâmetros que a rede deve suportar: roteamento multicast, distribuição de tempo PTP e marcação de qualidade de serviço (QoS) para o tráfego de áudio. Esta flexibilidade permite que o AES67 execute redes Ethernet Gigabit padrão, embora sejam recomendados switches especializados com suporte PTP e jitter baixo para implantações grandes ou críticas.

Principais recursos em detalhe

Interoperabilidade entre fornecedores

A principal característica do AES67 é a sua capacidade de ponte de sistemas proprietários. Por exemplo, um console de mistura baseado em Dante pode receber áudio de um pré-amplificador de microfone conectado com Ravenna se ambos forem compatíveis com AES67. Isto elimina a necessidade de vários adaptadores de rede ou caixas de conversão, simplificando o design do sistema e reduzindo o custo. A interoperabilidade é alcançada através de aderência estrita aos parâmetros de crocagem, empacotamento e sincronização de mídia definidos no padrão. Na prática, isso significa que um dispositivo da Yamaha (Dante) pode transmitir áudio para um dispositivo do Lawo (Ravenna) sem qualquer configuração especial além de permitir o modo AES67 e definir parâmetros de PTP corretos.

Desempenho de baixa latência

O AES67 foi desenhado para áudio em tempo real. Ele suporta streaming unicast e multicast, sendo o método de multicast o preferido para distribuição ponto- a- multiponto. O padrão permite latência tão baixa quanto 1 milissegundo (em modo de tempo de pacote de 1 milissegundo) para fluxos de 48 kHz, embora as implementações práticas usem frequentemente 4 milissegundos ou 8 milissegundos para equilibrar a sobrecarga da rede e a confiabilidade. Esta baixa latência é fundamental para reforço de som ao vivo, monitoramento no ouvido e aplicações de transmissão onde o atraso deve ser imperceptível. Em 4 ms de tempo de pacote, a latência de ponta a ponta normalmente permanece abaixo de 10 ms quando incluindo propagação de rede, tamponamento e processamento.

Sincronização de precisão com PTP

Todas as redes AES67 dependem do IEE 1588–2008 Precision Time Protocol (PTP) para sincronizar relógios de áudio entre dispositivos. O PTP oferece precisão de microsegundo nível, garantindo que todos os dispositivos samplem áudio exatamente ao mesmo tempo. Isto elimina o desvio de tempo e evita artefatos sonoros como pops, cliques ou cancelamento de fase. O padrão manda um perfil PTP (muitas vezes o perfil padrão ou o perfil específico AES67) com um intervalo de sincronização de 1 segundo e um intervalo de anúncio de 2 segundos. A configuração PTP adequada é a fonte mais comum de problemas nas implementações AES67, então os engenheiros de rede devem priorizar o tráfego PTP e garantir uma distribuição de tempo precisa.

Para instalações críticas à missão, usar um relógio grandster GPS ou um relógio de limite no switch de rede pode melhorar drasticamente a estabilidade.

Escalabilidade para qualquer rede de tamanho

AES67 escalas de conexões simples ponto- a- ponto para plantas de transmissão em grande escala com centenas de fluxos. Como usa multicast IP padrão, a largura de banda pode ser gerenciada com IGMP bisbilhotando e configuração adequada de switch. O padrão não impõe um número máximo de dispositivos ou fluxos, mas a capacidade de rede deve ser planejada de acordo. Com 1 Gbps Ethernet, centenas de fluxos estéreo de 48 kHz/ 24 bits podem fluir sem problemas. Velocidades mais altas (10 Gbps ou mais) permitem sistemas ainda maiores, tornando o AES67 adequado para estádios, centros de convenções e backbones de áudio de rede.

Por exemplo, uma grande instalação de transmissão pode executar 200 fluxos + simultaneamente usando uma espinha dorsal de 10 Gbps com interruptores redundantes.

Por que a AES67 é crucial para fluxos de trabalho de áudio modernos

Na indústria de áudio de hoje, nenhum único fabricante domina todas as categorias de produtos. Um estúdio de transmissão pode usar um console Lawo (Ravenna-based), microfones sem fio Shure (Dante) e monitores Genelec (AES67 via Dante ou Ravenna). Sem AES67, integrar esses sistemas exigiria adaptadores proprietários ou hardware de conversão caro. A AES67 elimina esse atrito, permitindo que os profissionais de áudio escolham a melhor ferramenta para cada trabalho sem se preocupar com compatibilidade.

Além disso, a AES67 suporta áudio de alta qualidade, sem compressão, atendendo às demandas de ambientes de escuta críticos. Para os radiodifusores, o padrão permite uma integração perfeita com o ST 2110 (padrão SMPTE para mídia profissional em IP), pois a AES67 forma a camada de transporte de áudio para ST 2110-30 e ST 2110-31. Isso faz da AES67 uma tecnologia fundamental para as instalações de transmissão baseadas em IP que transigem do SDI para IP. Em som ao vivo, a AES67 permite que os sistemas de touring integrem equipamentos de aluguel de diferentes fornecedores sem reconfigurar toda a rede.

Adotando investimentos AES67 também à prova de futuro. Por ser um padrão aberto não vinculado a nenhum único fornecedor, o equipamento comprado hoje permanece compatível com sistemas futuros que suportam AES67. Isso reduz o custo e a complexidade a longo prazo, especialmente em instalações de grande escala onde os ciclos de atualização de tecnologia são longos. Além disso, AES67 tem um caminho claro de atualização para AES X192 (atualmente em desenvolvimento), o que promete densidades de canais mais elevadas e redundância melhorada.

Fundação Técnica da AES67

Transporte: RTP e Payload Tipos

O AES67 usa o RTP para transportar dados de áudio sobre redes UDP/IP. O padrão requer suporte para o tipo de carga útil L24 (com 24 bits de PCM linear) e permite que o áudio seja de 16 bits e 20 bits. Cada pacote RTP contém um número fixo de amostras de áudio, determinado pelo tempo de pacote (1 ms, 4 ms ou 8 ms). O cabeçalho RTP inclui uma data- limite derivada do relógio PTP, permitindo que os receptores reconstruam o sinal de áudio com precisão, mesmo em redes não determinísticas. O RTP também fornece números de sequência que ajudam a detectar perda de pacotes e entrega fora de ordem. Para redundância, algumas implementações suportam FEC (Forward Error Correction) mas isto não faz parte da especificação principal AES67.

Sincronização: Domínios PTP e Relógio

O relógio de grande dimensão PTP fornece a base de tempo para todos os dispositivos. Pode ser um dispositivo de hardware dedicado (por exemplo, um relógio de grande dimensão PTP de Meinberg ou um interruptor Ethernet com capacidades de relógio limite) ou uma implementação de software (com menor precisão). Todos os terminais AES67 devem ser capazes de sincronizar com o domínio PTP e gerar relógios de áudio bloqueados com o tempo PTP. O padrão permite redundância, suportando vários mega- sistemas PTP numa configuração de standby. Na prática, a maioria das implementações AES67 usa um único grande mestre, muitas vezes a consola de mistura ou uma fonte de relógio dedicada. O número de domínio PTP deve ser consistente em toda a rede; o domínio 0 é comum, mas alguns fabricantes recomendam o domínio 1 para AES67.

Descoberta de Stream: Protocolo de Descrição de Sessão e SAP

Para encontrar fluxos na rede, os dispositivos AES67 usam o SAP para anunciar sessões RTP. Cada anúncio contém um arquivo Session Description Protocol (SDP) que descreve os parâmetros do fluxo: IP de origem, endereço multicast de destino, tipo de carga útil RTP, taxa de amostragem, número de canais e domínio PTP. Os dispositivos escutam esses anúncios e podem então se inscrever nos fluxos desejados. Algumas implementações também suportam streaming unicast para conexões ponto-a-ponto onde multicast não está disponível ou desejado. SAP usa endereço multicast 239,255.0.1 e UDP port 9875.

Em redes maiores, o snoooping IGMP deve ser configurado para evitar que os anúncios SAP inundem todas as portas.

AES67 vs. Outros Protocolos AoIP

Vários protocolos AoIP dominam o mercado de áudio profissional. Compreender como a AES67 se relaciona com eles é importante para o design do sistema.

Protocolo Relação com a AES67 Diferenças-chave
DanteDante da Audinate é um sistema proprietário, mas oferece suporte AES67 em muitos produtos desde Dante firmware 4.0. Dante dispositivos podem ser configurados para saída de fluxos AES67, permitindo a interoperabilidade com equipamentos não-Dante.Dante usa seu próprio relógio e descoberta (Dante Controller). O modo AES67 pode perder algumas características específicas do Dante (como assinaturas unicast ou contagens de canais acima de 2).
RavennaDesenvolvido pela Lawo e ALC Network, Ravenna é baseado na AES67 e estende-o com recursos adicionais como fluxos redundantes, contagens de canais mais altas e roteamento flexível. Os dispositivos Ravenna são compatíveis com o AES67 por design.Ravenna oferece gerenciamento de rede mais avançado e suporta até 256 canais por fluxo, enquanto AES67 limita a base para 2 canais por fluxo (embora vários fluxos possam ser empacotados).
AVB / TSNIEEE 1722 AVB (Audio Video Bridging) e seu sucessor TSN (Time-Sensitive Networking) fornecem transporte determinístico com baixo jitter. AES67 pode executar através de redes AVB se configurado corretamente, mas AVB requer switches especiais e endpoints.AVB/TSN garante largura de banda e latência, enquanto AES67 depende de redes IP de melhor esforço com sincronização PTP. AVB é mais complexo e caro, mas oferece maior confiabilidade para aplicações críticas.
Fio Vivo Usado por Axia e Telos, o LiveWire é um sistema AoIP proprietário popular em rádio de transmissão. Alguns dispositivos LiveWire suportam AES67, mas não todos. Interoperabilidade muitas vezes requer um gateway.O LiveWire tem seu próprio sistema de controle e monitoramento, que pode não estar disponível quando estiver usando o modo AES67.

Para a maioria dos profissionais de áudio, o AES67 atua como uma ponte universal. Permite que um console Dante fale com uma caixa de E/S Ravenna, ou um array de microfone baseado em AVB para enviar áudio para uma consola de transmissão que só suporta o AES67. A chave é garantir que os dispositivos estejam configurados adequadamente e que a infraestrutura de rede atenda aos requisitos para PTP e multicast.

Vale também notar que muitos dispositivos modernos AoIP suportam vários modos. Por exemplo, um único interruptor pode transportar simultaneamente fluxos Dante/AES67 e Ravenna/AES67, desde que eles usem o mesmo domínio PTP e tempos de pacotes compatíveis. Esta flexibilidade torna AES67 uma excelente escolha para ambientes heterogêneos.

Implementação da AES67 em sua configuração

A implantação com sucesso da AES67 requer um planejamento cuidadoso e atenção ao design de rede. Siga estes passos para integrar a AES67 em seu sistema de áudio.

Passo 1: Verificar a Compatibilidade do Dispositivo

Verifique se o seu equipamento existente suporta o AES67. Muitos dispositivos Dante modernos têm uma configuração de firmware para activar o modo AES67. Os dispositivos Ravenna estão normalmente prontos para AES67 por omissão. Para os equipamentos mais antigos, poderá necessitar de uma caixa de conversores AES67 dedicada (por exemplo, a partir do DirectOut, Digigram ou Neutrik). Documente as taxas de amostragem, os tempos de pacotes e os perfis PTP suportados de cada dispositivo. Alguns dispositivos poderão necessitar de uma actualização de licença ou firmware para desbloquear a funcionalidade AES67.

Passo 2: Desenhe a rede

AES67 funciona melhor em uma rede de áudio dedicada ou segmentada usando switches Gigabit Ethernet com baixa latência e suporte para o IGMP snooping, relógio transparente PTP ou relógio limite, e priorização da qualidade do serviço (QoS). Os switches recomendados incluem Cisco Catalyst série 3850, Netgear série M4300 ou série Luminex GigaCore. Evite interruptores de nível de consumo, pois eles não podem lidar com multicast de forma eficiente ou adicionar jitter excessivo. Para instalações grandes, considere usar uma topologia de núcleo/distribuição com links redundantes.

Para o PTP, designe um dispositivo como o relógio de grande dimensão. Este deve ser um dispositivo com um oscilador estável (de preferência um grande mestre de hardware PTP ou uma consola de mistura com um relógio interno de alta precisão). Todos os outros dispositivos devem ser configurados como relógios de escravos. Certifique-se de que as mensagens PTP recebem a maior prioridade na rede (DSCP 46 ou 56 para mensagens de eventos PTP). O QoS também deve ser aplicado ao tráfego de áudio RTP (DSCP 56 ou 46) para evitar a perda de pacotes sob congestionamento.

Passo 3: Configurar o PTP

Defina o número de domínio PTP de forma consistente em todos os dispositivos (comunicavelmente domínio 0 ou domínio 1 para AES67). Configure as configurações do relógio de grande dimensão – use o perfil AES67 se disponível. Para a maioria das implementações, recomenda- se um modo de relógio de dois passos para a precisão. Uma vez que o PTP esteja em execução, verifique se todos os escravos relatam estar sincronizados com o grande mestre em alguns microssegundos. Muitos dispositivos têm um estado de LED ou interface web indicando o bloqueio PTP. Use o Wireshark ou uma ferramenta de monitorização PTP para verificar a precisão do relógio do grande mestre e o deslocamento dos escravos.

Passo 4: Configurar os Fluxos

Usando o software do dispositivo (por exemplo, Dante Controller, Ravenna Network Manager ou aplicativos específicos do fabricante), crie remetentes e receptores. Cada fluxo deve ter um endereço multicast único (no intervalo 239.192.0.0/14 é típico para AES67). Configure a mesma taxa de amostragem, profundidade de bits e tempo de pacote em ambas as extremidades. Para interoperabilidade, são suportados tempos de pacote de 1 ms, 4 ms ou 8 ms – mas todos os dispositivos devem usar o mesmo tempo de pacote para um determinado fluxo. 4 ms é um bom equilíbrio porque é amplamente compatível e oferece latência aceitável. Se um dispositivo só suporta 1 ms, certifique-se que a rede pode lidar com a maior taxa de pacotes sem soltar frames.

Passo 5: Teste e Valide

Após a configuração, verifique se o áudio está fluindo corretamente. Ouça quaisquer falhas, falhas ou erros de sincronização. Use ferramentas de diagnóstico de rede como o WireShark com o dissector AES67 ou ferramentas de teste dedicadas ao AoIP (por exemplo, Precisão de Áudio APx500 com opção AoIP ou ferramentas N. V. L. L. A. B.). Verifique se o deslocamento do PTP permanece abaixo de 1 microsegundo e que a perda de pacotes é inferior a 0,01%. Realize testes de carga com o número esperado de fluxos. Para as instalações de transmissão, verifique também a conformidade com o ST 2110-30, se aplicável.

Passo 6: Manter e Monitorar

Uma vez que o sistema esteja operacional, configure o monitoramento contínuo. Use o SNMP para rastrear portas de comutação, status PTP e assinatura de fluxo. Implemente grandes mestres PTP redundantes, se necessário, para instalações críticas. Mantenha o firmware do dispositivo atualizado conforme os fabricantes melhorarem a compatibilidade e desempenho AES67. Documente a topologia da rede, endereços IP, grupos multicast e configurações PTP para referência futura.

Desafios comuns e como superá - los

Mesmo com planejamento cuidadoso, as implantações da AES67 podem encontrar problemas. Aqui estão os problemas mais frequentes e suas soluções.

  • Falha na sincronização do PTP: Causada por seleção inadequada de grandes mestres, hops de rede excessivos ou switches que não suportam o relógio transparente PTP. Solução: Use switches com suporte de PTP de hardware, minimize o hop e garanta que o grandester tenha uma fonte de tempo estável (por exemplo, GPS). Também verifique que nenhum outro domínio PTP está interferindo.
  • Desistências de áudio ou distorção: Muitas vezes devido ao congestionamento da rede, configurações incorretas de QoS ou tempos de pacote desiguais. Solução: Priorize o tráfego de áudio (DSCP 56 para RTP), isole a rede de áudio do tráfego de dados em geral e confirme que todos os dispositivos usam o mesmo tempo de pacote. Verifique se há perda de pacotes usando estatísticas do interruptor ou dispositivo.
  • O dispositivo não consegue descobrir os fluxos: Os anúncios SAP podem ser bloqueados por IGMP bisbilhotando ou firewalls. Solução: Habilite o IGMP querier no interruptor, garanta que o multicast é permitido e verifique se o endereço de destino SAP (239.255.0.1) é routable. Alguns dispositivos podem precisar de multicast para ser ativado no VLAN.
  • Aumento da latência ao longo do tempo: A deriva do relógio entre dispositivos pode acumular-se. Solução: Verifique a qualidade do bloqueio PTP e que os dispositivos não estão a cair para o relógio de funcionamento livre. Alguns dispositivos podem necessitar de uma configuração periódica do PTP. Use um grande mestre dedicado com disciplina GPS para estabilidade a longo prazo.
  • Interoperabilidade entre dispositivos específicos: Algumas combinações podem ter erros de parâmetros sutis (por exemplo, tipo de carga útil RTP 96 vs. custom). Solução: Verifique a documentação do fabricante para modos de compatibilidade conhecidos e contate o suporte se necessário. Às vezes, usar um controlador de terceiros (como o Mergeing’s Aneman) pode ajudar a negociar parâmetros.
  • Inundações multicast: Sem o IGMP bisbilhotando, os fluxos multicast podem inundar todas as portas de comutação, causando problemas de largura de banda. Solução: Habilite o IGMP bisbilhotando e configure um querier. Use as portas de comutação para limitar a distribuição multicast apenas para os dispositivos que precisam do fluxo.

O Futuro da AES67

A AES67 continua evoluindo. A AES publicou atualizações para o padrão, e continua sendo um item de trabalho ativo. Um dos principais desenvolvimentos é sua integração com o SMPTE ST 2110 para produção de transmissão, que usa o AES67 como transporte de áudio. Como mais instalações de transmissão transição para fluxos de trabalho baseados em IP, a AES67 desempenhará um papel central. Além disso, a Audio Engineering Society está trabalhando no AES X192, um padrão de próxima geração que pode abordar maior densidade de canal, formatos de fluxo mais flexíveis e redundância melhorada.

Outra tendência é a convergência da AES67 com o AVB/TSN. Alguns fabricantes oferecem dispositivos que podem operar tanto nos modos AES67 quanto AVB, permitindo que os usuários escolham entre redes IP de baixo custo (AES67) ou transporte determinístico garantido (AVB). À medida que os switches TSN se tornam mais acessíveis, as redes híbridas podem se tornar comuns, onde áudio crítico recebe a garantia TSN e áudio menos crítico usa roteamento IP padrão.

Finalmente, a comunidade de código aberto abraçou a AES67. Projetos como PipeWire e Jack Audio Connection Kit têm suporte a AES67, permitindo que estações de trabalho de áudio baseadas em Linux se conectem a redes profissionais AoIP. Isso reduz a barreira à entrada para pequenos estúdios e profissionais de áudio independentes. Além disso, os fornecedores estão oferecendo cada vez mais terminais AES67 definidos por software que podem ser executados em servidores padrão, reduzindo os custos de hardware.

À medida que a indústria avança para infraestruturas de todo o IP, o papel da AES67 como camada de interoperabilidade só vai crescer. A adoção da AES67 em novos segmentos, como áudio automotivo, sistemas de intercomunicação e áudio distribuído está expandindo o alcance do padrão além do áudio profissional tradicional.

Conclusão

A AES67 mudou fundamentalmente a forma como os profissionais de áudio pensam sobre áudio em rede. Ao fornecer uma camada de interoperabilidade comum, permite que os equipamentos de diferentes fabricantes trabalhem em conjunto de forma perfeita, reduzindo o custo e a complexidade do sistema, mantendo o alto desempenho necessário para aplicações profissionais. Se você está projetando uma planta de transmissão, uma turnê de som ao vivo ou uma instalação fixa, o entendimento da AES67 lhe fornece as ferramentas para construir redes de áudio mais flexíveis e confiáveis. Com planejamento, configuração e infraestrutura de rede adequada, a AES67 pode ser um poderoso aliado em seu kit de ferramentas de áudio.

Para mais informações, consultar a especificação oficial AES67 disponível no Sociedade de Engenharia de Áudio, e explorar guias de implementação de fornecedores como Audiato e Rede ALC. Dicas práticas de design de rede podem ser encontradas no Ponte de Transmissão série de artigos. Para um mergulho profundo na sincronização PTP, consulte a especificação IEEE 1588 e recursos de MeinbergA adoção da AES67 hoje significa investir em um padrão aberto que continua crescendo e evoluindo ao lado da indústria de áudio.