Dante vs AES67 vs AVB: Comparativo Técnico de Áudio sobre IP

O que são protocolos de áudio sobre IP

Áudio sobre IP (AoIP) é o transporte de sinais de áudio digital por redes Ethernet padrão, substituindo cabeamento analógico ponto a ponto por infraestrutura de rede compartilhada. Em vez de dezenas de cabos dedicados entre cada fonte e cada destino, o AoIP roteia múltiplos canais em um único cabo de rede, com flexibilidade, escalabilidade e gerenciamento centralizado.

Na prática, um microfone em uma sala de reuniões pode alimentar simultaneamente a mesa de operação, o sistema de gravação e a videoconferência — tudo pela mesma rede, sem cabeamento dedicado para cada percurso. O roteamento é feito por software, não por reconexão física de cabos.

O conceito se estende naturalmente para o AV sobre IP, que inclui também o transporte de vídeo sobre a mesma infraestrutura. Porém, no domínio específico do áudio profissional, três protocolos dominam o mercado: Dante, AES67 e AVB/Milan.

Cada um resolve o mesmo problema — transportar áudio em tempo real sobre Ethernet — com arquiteturas, premissas de rede e compromissos diferentes. A escolha impacta o design da rede, a seleção de switches, a interoperabilidade com o parque existente e o custo total do projeto.

Em ambientes como centros de operações, auditórios governamentais e salas de controle, a decisão do protocolo AoIP afeta todas as camadas do projeto, da especificação dos switches à manutenção preventiva e ao comissionamento.

Dante — o padrão de facto do mercado

Desenvolvido pela Audinate (Austrália), o Dante (Digital Audio Network Through Ethernet) é o protocolo AoIP com maior adoção no mercado profissional. Com milhares de produtos compatíveis de centenas de fabricantes, o Dante se consolidou como padrão de facto para áudio em rede em instalações comerciais, corporativas e governamentais.

Como funciona a arquitetura Dante

O Dante transporta áudio digital não comprimido sobre redes Ethernet padrão (100 Mbps ou Gigabit). O protocolo opera em Layer 3 (IP), o que significa que os pacotes de áudio podem atravessar switches, VLANs e até roteadores — desde que a rede esteja configurada corretamente para suportar os requisitos de QoS e multicast.

Os componentes fundamentais da arquitetura são:

• Descoberta de dispositivos: utiliza mDNS (multicast DNS) para que equipamentos se encontrem automaticamente na rede, sem configuração manual de endereços IP. Quando um dispositivo Dante é conectado à rede, ele se anuncia e se torna visível no Dante Controller em segundos;
• Transporte de áudio: suporta unicast (ponto a ponto) e multicast (um para muitos). A seleção entre unicast e multicast pode ser automática ou manual — multicast é mais eficiente quando um transmissor alimenta muitos receptores simultaneamente;
• Sincronismo: baseado em PTP (Precision Time Protocol, IEEE 1588), que garante alinhamento de amostras entre dispositivos com precisão na ordem de microssegundos. O PTP elege um relógio de referência (clock leader) na rede e todos os dispositivos sincronizam seus relógios internos a partir dele;
• Latência: configurável — tipicamente 1 ms, 2 ms ou 5 ms, dependendo do tamanho da rede e do número de saltos (hops) entre switches. Redes menores suportam 1 ms; redes com três ou mais níveis de switches podem exigir configurações de latência mais altas;
• Resolução: PCM não comprimido, até 32 bits / 96 kHz por canal nos dispositivos mais comuns, com suporte a centenas de canais simultâneos dependendo da largura de banda disponível.

Gerenciamento: Dante Controller e Domain Manager

O Dante Controller é o software gratuito que funciona como a matriz de roteamento do sistema. Nele, o operador define quais transmissores (Tx) alimentam quais receptores (Rx), visualiza o status de sincronismo, monitora latência e identifica problemas de rede. É a ferramenta do dia a dia de qualquer instalação Dante, da sala de reuniões ao campus.

Para instalações de maior porte ou que exigem governança, o Dante Domain Manager adiciona camadas de segurança, auditoria e gerenciamento centralizado. Ele permite:

• Criar domínios de áudio isolados (segregação lógica de dispositivos);
• Controlar acesso por usuário com RBAC (controle de acesso baseado em papéis);
• Monitorar a saúde dos dispositivos em painel centralizado;
• Integrar com sistemas de monitoramento existentes via SNMP;
• Manter registro de auditoria de alterações de configuração;
• Gerenciar a descoberta de dispositivos por DNS em vez de mDNS (necessário para redes com roteamento entre sub-redes).

Vantagens do Dante

• Ecossistema: o maior do mercado AoIP — milhares de produtos de centenas de fabricantes, cobrindo microfones, amplificadores, processadores, mesas de som, matrizes e interfaces;
• Infraestrutura: opera sobre switches Ethernet gerenciáveis padrão, sem necessidade de hardware especializado;
• Roteabilidade: suporta Layer 3, permitindo áudio entre sub-redes e VLANs;
• Ferramentas: Dante Controller e Domain Manager são ferramentas maduras, com interface intuitiva e documentação extensa;
• Compatibilidade AES67: dispositivos Dante podem operar em modo AES67, habilitando interoperabilidade com outros ecossistemas.

Limitações do Dante

• Licenciamento proprietário: o ecossistema depende da Audinate. Funcionalidades avançadas de gerenciamento (Domain Manager) exigem licenças adicionais;
• QoS dependente de configuração: o determinismo de rede não é nativo — depende de QoS (DiffServ/DSCP) configurado corretamente nos switches. Configuração incorreta causa artefatos;
• Multicast exige IGMP: sem IGMP snooping habilitado, fluxos multicast inundam a rede. É um problema de configuração, não do protocolo, mas é a causa mais frequente de problemas em campo;
• Não funciona por Wi-Fi: áudio Dante exige conexão Ethernet cabeada. Não há suporte para transporte de áudio por redes sem fio.

AES67 — o padrão aberto de interoperabilidade

O AES67 é um padrão publicado pela Audio Engineering Society (AES) com foco em interoperabilidade entre protocolos e ecossistemas de AoIP. Não é um sistema completo de gerenciamento de áudio em rede — é uma especificação de transporte e sincronismo que define o denominador comum para que dispositivos de fabricantes e protocolos diferentes troquem áudio entre si.

O AES67 é a "língua franca" do áudio sobre IP: não substitui Dante, Ravenna ou Livewire, mas permite que dispositivos desses ecossistemas se comuniquem.

Especificações técnicas do AES67

• Transporte: RTP (Real-time Transport Protocol) sobre UDP/IP — padrão aberto, amplamente documentado e implementado;
• Sincronismo: PTP IEEE 1588-2008, a mesma base utilizada pelo Dante;
• Descoberta: SDP (Session Description Protocol) e SAP (Session Announcement Protocol) são os mecanismos definidos pelo padrão. Na prática, a descoberta pode ser delegada ao protocolo nativo do dispositivo (ex.: mDNS no Dante com modo AES67);
• Resolução: PCM linear, 16 ou 24 bits, com taxas de amostragem de 44,1 kHz a 96 kHz;
• Latência: tipicamente a partir de 1 ms, dependendo da implementação e da rede;
• Camada: Layer 3 (IP), roteável entre sub-redes.

Relação entre AES67 e Dante

Dispositivos Dante podem operar em modo AES67, permitindo interoperabilidade com outros ecossistemas compatíveis. Na prática, um dispositivo Dante configurado para AES67 pode enviar e receber fluxos de áudio para dispositivos Ravenna, Livewire ou qualquer outro que implemente o padrão AES67.

A habilitação do modo AES67 é feita no Dante Controller, e a rede precisa estar configurada para suportar os fluxos multicast adicionais. Não é um "modo degradado" — é uma camada de interoperabilidade que coexiste com o funcionamento Dante nativo.

Quando o AES67 é essencial

O AES67 se torna relevante em cenários específicos:

• Broadcast: ambientes que utilizam SMPTE ST 2110 dependem do AES67 como camada de transporte de áudio (ST 2110-30). Qualquer instalação de broadcast baseada em IP precisa de compatibilidade AES67;
• Integração multiecossistema: quando o projeto envolve equipamentos de fabricantes que utilizam protocolos diferentes (Dante + Ravenna, por exemplo), o AES67 é a ponte de interoperabilidade;
• Política de padrões abertos: organizações com políticas de aquisição que exigem padrões abertos podem especificar AES67 como requisito de interoperabilidade;
• Infraestrutura legada: quando já existem dispositivos AES67 na rede e novos equipamentos precisam interoperar com eles.

AVB/TSN e perfil Milan — determinismo nativo em Layer 2

AVB (Audio Video Bridging) é um conjunto de padrões IEEE 802.1 que operam em Layer 2 (camada de enlace de dados), oferecendo garantias de tempo real diretamente no nível do switch Ethernet. Diferentemente de Dante e AES67, que dependem de QoS configurado nos switches para priorizar tráfego, o AVB incorpora mecanismos nativos de reserva de banda, sincronismo e controle de admissão.

O determinismo, portanto, não depende de configuração manual do administrador de rede — é garantido pelo protocolo. Quando um dispositivo solicita um fluxo (stream) de áudio, o caminho completo é verificado e a banda é reservada antes de a transmissão iniciar. Sem recursos suficientes, o fluxo não é estabelecido — em vez de degradar silenciosamente.

Padrões IEEE que compõem o AVB

• IEEE 802.1AS (gPTP): sincronização de relógio generalizada — uma variante do PTP otimizada para redes comutadas, com precisão suficiente para alinhamento de amostras de áudio entre dispositivos;
• IEEE 802.1Qav (FQTSS): modelagem de tráfego (traffic shaping) baseada em crédito, que garante que fluxos de mídia não sofram jitter excessivo ao compartilhar a rede com outros tipos de tráfego;
• IEEE 802.1Qat (SRP): protocolo de reserva de fluxo — cada fluxo de áudio ou vídeo reserva banda no caminho completo (de switch em switch) antes de iniciar a transmissão. Isso elimina o risco de congestionamento não detectado;
• IEEE 1722 (AVTP): protocolo de transporte de mídia sobre redes AVB, definindo como os dados de áudio e vídeo são encapsulados nos quadros Ethernet.

Esses padrões evoluíram para o conceito mais amplo de TSN (Time-Sensitive Networking), que estende as garantias de tempo real do AVB a aplicações industriais e automotivas. No áudio profissional, a referência prática continua sendo o AVB com o perfil Milan.

Perfil Milan: interoperabilidade certificada

O perfil Milan, desenvolvido pela Avnu Alliance, é uma camada de certificação sobre o AVB que define requisitos obrigatórios de implementação. O objetivo é simples: garantir que dispositivos de diferentes fabricantes se comuniquem corretamente em redes AVB.

Sem Milan, dois dispositivos AVB de fabricantes diferentes podem implementar o padrão de formas incompatíveis. Com Milan, a interoperabilidade é certificada, testada e verificável. Fabricantes de sistemas de PA e processamento de grande porte adotaram o perfil Milan para turnês, broadcast e instalações fixas de grande escala.

Vantagens do AVB/Milan

• Determinismo nativo: reserva de banda e controle de admissão garantidos pelo protocolo, não por configuração manual de QoS;
• Previsibilidade: latência garantida (tipicamente inferior a 2 ms), não apenas "configurável";
• Padrão aberto: baseado em IEEE, sem royalties de licenciamento por protocolo;
• Certificação Milan: interoperabilidade testada e verificada entre fabricantes.

Limitações do AVB/Milan

• Switches específicos: exige switches compatíveis com AVB. Switches Ethernet corporativos padrão não suportam os padrões IEEE 802.1AS, 802.1Qav e 802.1Qat;
• Layer 2 apenas: AVB não é roteável. O áudio não pode atravessar roteadores ou ser transportado entre sub-redes IP. O escopo é limitado ao domínio de broadcast Layer 2;
• Ecossistema menor: comparado ao Dante, o número de produtos compatíveis com AVB/Milan é significativamente menor, concentrado no segmento de pro áudio;
• Infraestrutura dedicada: a necessidade de switches AVB torna a integração com redes corporativas existentes mais complexa.

Comparação técnica: Dante vs AES67 vs AVB/Milan

A tabela abaixo sintetiza as diferenças técnicas e práticas entre os três protocolos; o contexto de cada critério está nas seções anteriores.

Erros comuns em projetos de áudio sobre IP

A maioria dos problemas em sistemas AoIP não vem do protocolo escolhido — vem de erros de design de rede, configuração ou expectativas desalinhadas. Estes são os erros mais recorrentes que encontramos em campo.

Erro 1: usar switches não gerenciáveis para Dante ou AES67

Switches domésticos ou não gerenciáveis não suportam QoS (DiffServ/DSCP), IGMP snooping ou VLANs. Sem isso, o áudio compete em igualdade com todo o tráfego da rede e os fluxos multicast inundam todas as portas. O resultado: cortes (dropouts), artefatos, latência variável e falhas intermitentes de descoberta de dispositivos.

Solução: especificar switches Ethernet gerenciáveis com suporte a VLAN (802.1Q), DiffServ QoS, IGMP snooping (v2/v3) e latência de encaminhamento previsível, e desabilitar EEE (Energy Efficient Ethernet) nas portas de áudio. Os requisitos completos estão no guia de rede para AV sobre IP.

Erro 2: não configurar QoS e tratar a rede como "plug and play"

Ver que o Dante "funciona" ao ser conectado não significa rede configurada corretamente. Com baixa utilização, o áudio flui mesmo sem QoS. Sob carga — tráfego corporativo, backups, downloads — os pacotes de áudio perdem prioridade e os artefatos aparecem.

Solução: configurar QoS com marcação DiffServ/DSCP em todos os switches do caminho de áudio. Priorizar: sincronismo (PTP) no nível mais alto, áudio no nível seguinte, controle/gerenciamento abaixo. Consultar a documentação do fabricante para os valores DSCP recomendados.

Erro 3: ignorar IGMP snooping em redes com multicast

Quando um transmissor Dante alimenta múltiplos receptores, ele envia multicast. Sem IGMP snooping, o switch trata esse tráfego como broadcast — replicando para todas as portas e consumindo banda e processamento de todos os dispositivos. Com dezenas de fluxos multicast, a rede satura rapidamente.

Solução: ativar IGMPv2 ou IGMPv3 snooping em todos os switches da rede de áudio, com um querier IGMP ativo na VLAN. Verificar se o switch tem capacidade de processamento para o número de grupos multicast do projeto.

Erro 4: misturar áudio e dados corporativos na mesma VLAN

Tráfego AoIP é extremamente sensível a latência e jitter. Na mesma VLAN dos dados corporativos — e-mail, navegação, transferência de arquivos, backups — qualquer pico de utilização pode causar impacto perceptível no áudio, mesmo com QoS configurado.

Solução: isolar o tráfego de áudio em uma VLAN dedicada. Em projetos maiores, considerar VLANs separadas para áudio, controle/gerenciamento AV e tráfego de dados corporativo. Documentar o design de VLAN no projeto executivo.

Erro 5: especificar AVB sem validar switches e escopo

Especificar AVB/Milan onde os switches existentes não são compatíveis com AVB gera incompatibilidade fundamental. O AVB não é uma configuração de software — depende de hardware que implemente os padrões IEEE 802.1AS, 802.1Qav e 802.1Qat. E, como opera em Layer 2, não roteia áudio entre sub-redes, limitação crítica em campus ou prédios com segmentação de rede existente.

Solução: antes de especificar AVB, validar: (1) os switches do projeto são compatíveis com AVB? (2) todos os dispositivos de áudio são certificados Milan? (3) o escopo de rede é Layer 2 puro, sem necessidade de roteamento IP entre sub-redes?

Critérios de decisão: quando usar cada protocolo

A escolha do protocolo depende de quatro fatores principais: ecossistema de equipamentos, infraestrutura de rede disponível, requisitos de interoperabilidade e escala e contexto do projeto.

Escolha Dante quando

• O projeto envolve equipamentos de múltiplos fabricantes e a maioria já suporta Dante;
• A rede existente é Ethernet gerenciável padrão (sem necessidade de switches AVB);
• É necessário roteamento entre VLANs ou sub-redes (Layer 3);
• O projeto exige gerenciamento centralizado com Domain Manager (governança, auditoria, RBAC);
• A prioridade é ecossistema amplo, ferramentas maduras e suporte consolidado;
• O ambiente é uma instalação fixa em órgão público — auditório ou plenária, sala de conferência, centro de comando;
• O projeto precisa de documentação técnica robusta para termo de referência ou pregão eletrônico.

Escolha AES67 quando

• O projeto precisa integrar equipamentos de ecossistemas diferentes (Dante + Ravenna + Livewire, por exemplo);
• O ambiente é de broadcast e precisa de compatibilidade com SMPTE ST 2110;
• A organização tem política de aquisição que exige padrões abertos;
• Já existem dispositivos AES67 na infraestrutura e a interoperabilidade é requisito;
• O projeto envolve integração com sistemas de televisão, rádio ou produção de conteúdo ao vivo.

Escolha AVB/Milan quando

• O projeto é de pro áudio em larga escala (PA, turnês, auditórios de grande porte);
• O determinismo de rede é crítico e você não quer depender de configuração manual de QoS nos switches;
• Os fabricantes dos equipamentos principais já são certificados Milan;
• A infraestrutura de switches será dedicada ao áudio (não compartilhada com TI corporativa);
• O escopo é Layer 2 puro e não há necessidade de roteamento IP entre sub-redes;
• O projeto aceita o custo de switches compatíveis com AVB.

Abordagem pragmática para a maioria dos projetos

Na prática, para a maioria dos projetos de instalação fixa em órgãos públicos e ambientes corporativos no Brasil — auditórios, salas de conferência, salas de crise, centros de operação — o Dante continua sendo a escolha mais pragmática: ecossistema amplo, ferramentas maduras, compatibilidade com switches gerenciáveis padrão (menor custo de infraestrutura) e documentação técnica extensa para especificação em licitações.

Quando houver necessidade de interoperabilidade com broadcast ou outros ecossistemas, habilite o modo AES67 nos dispositivos Dante — sem necessidade de trocar a infraestrutura.

AVB/Milan faz mais sentido em projetos de pro áudio dedicados, onde o investimento em switches AVB é justificado pelo determinismo nativo e a rede será exclusiva para áudio.

Como especificar o protocolo em licitação sem direcionar marca

Dante é proprietário, e a dúvida recorrente nos órgãos é se ele pode ser exigido no termo de referência. A Lei 14.133/2021 admite, excepcionalmente, indicar marca ou modelo quando formalmente justificado — por exemplo, padronização ou compatibilidade com plataformas e padrões já adotados pela Administração —, justificativa que em regra nasce no estudo técnico preliminar. A redação mais defensável, porém, descreve a função, não o nome: áudio sobre IP não comprimido, sincronismo PTP IEEE 1588, roteamento por software, unicast e multicast, interoperabilidade AES67. Isso preserva a competitividade e é atendido pelo ecossistema dominante sem excluir alternativas. Para os switches, exigir VLAN, QoS DiffServ, IGMP snooping e EEE desativável por porta é requisito funcional, não direcionamento — técnica detalhada em especificação sem marca.

Matheus Lourencatto — Engenharia Netfocus. Integração audiovisual para o governo federal desde 2009: 150+ projetos entregues em 50+ órgãos, SICAF ativo e SLA contratual de 4h. Fale com a engenharia →

Publicado em 14 Jul 2025 · Revisado em 22 Set 2026