A rede de áudio tornou-se a espinha dorsal de modernos ambientes de reforço de som ao vivo, produção de transmissão e gravação de estúdio. Como a indústria se transforma em uma infraestrutura tradicional analógica e ônibus digitais dedicados para Ethernet, a necessidade de transmissão de áudio confiável e de alta fidelidade em redes IP padrão nunca foi maior.O padrão AES67 – oficialmente intitulado “AES67-2018: padrão AES para aplicações de áudio de redes – interoperabilidade de áudio de streaming de alto desempenho – alta eficiência – aborda essa necessidade, fornecendo um framework comum que permite que os dispositivos de áudio de diferentes fabricantes comuniquem de forma perfeita. Um componente crítico do sucesso da AES67 é sua abordagem robusta da Qualidade de Serviço (QoS), que garante que os dados de áudio sensíveis ao tempo cheguem intactos, em ordem e na programação, mesmo quando a rede transporta outros dispositivos de tráfego. Este artigo explora todos os mecanismos essenciais de QoS dentro da AES67, oferece uma orientação de configuração concreta, e explica por que a implantação adequada do QoS separa um sistema profissional estável de um sistema flagrado por gotas e falhas.

O que é Qualidade de Serviço (QoS) na AES67?

Qualidade do Serviço é um termo amplo que engloba o conjunto de tecnologias e mecanismos usados para gerenciar recursos de rede e priorizar certos tipos de fluxos de dados. Em redes IP, todos os pacotes são tratados igualmente por padrão – uma situação chamada “melhor esforço” de entrega. Embora isso funcione bem para navegação na web, e- mail ou transferências de arquivos, é totalmente inaceitável para fluxos de áudio em tempo real, onde pacotes atrasados ou perdidos resultam em desistências, falhas ou perda completa de sincronização. O QoS altera isso atribuindo prioridade maior aos pacotes de áudio, garantindo que eles sejam encaminhados antes de menos tráfego crítico. Em uma implantação AES67, o QoS não é um complemento opcional; o padrão ordena comportamentos específicos que cada dispositivo compatível deve suportar, incluindo tanto Layer 3 (IP) quanto Layer 2 (Ethernet) mecanismos prioritários. Esta abordagem dual- layer dá aos designers de sistema a flexibilidade para implementar QoS em vários ambientes de rede, desde configurações simples de única-switch para redes complexas de amplas rotas que abrangem edifícios ou até mesmo cidades.

O papel da QoS na manutenção da integridade do áudio

Por que o QoS é tão crucial em uma rede AES67? A resposta está na natureza dos pacotes de áudio. Os fluxos AES67 normalmente carregam vários canais de áudio de Modulação de Código de Pulse (PCM) não comprimido, com tamanhos de pacotes projetados para minimizar a latência, mantendo a eficiência. Um fluxo típico do AES67 pode enviar pacotes a cada 125 microssegundos (para um pacote de 8 amostras a 48 kHz) ou a cada 1 milissegundo (para um pacote de 48 amostras). Qualquer variação significativa de atraso – chamada de “brilhante” – ou perda de pacotes irá degradar a qualidade do áudio.

O QoS aborda diretamente estes problemas por:

  • Redução da latência: A fila de prioridades garante que os pacotes de áudio passem menos tempo à espera em buffers de switch. Quando chega uma explosão de tráfego de transferência de arquivos, os pacotes não prioritários são em fila enquanto os pacotes de áudio saltam para a frente.
  • A minimizar o nervosismo: O tratamento de encaminhamento consistente através da rede mantém as horas de chegada previsíveis. Os receptores de áudio podem então usar pequenos buffers de jitter (frequentemente <1 ms) sem arriscarem os erros.
  • Eliminando a perda de pacotes: Ao reservar largura de banda e marcar pacotes, o QoS impede que o congestionamento force o lançamento de pacotes de áudio. Até mesmo um único pacote perdido pode produzir um clique audível, então a perda zero é o objetivo.

Além desses benefícios básicos, o QoS também protege os pacotes Precision Time Protocol (PTP) que sincronizam todos os dispositivos AES67. Se o tempo de PTP for atrasado ou perdido, toda a precisão do relógio da rede se degrada, levando a falhas de buffer ou ultrapassam todos os fluxos de áudio. Uma política de QoS bem configurada trata o tráfego de tempo com a mesma urgência que a carga útil de áudio.

Mecanismos chave QoS Definidos pela AES67

O padrão AES67 aproveita várias tecnologias de rede bem estabelecidas para alcançar suas garantias QoS. Esses mecanismos operam em diferentes camadas do modelo OSI e se complementam para criar uma camada de transporte de áudio confiável. Compreender cada mecanismo e como eles interagem é essencial para qualquer pessoa projetar, implantar ou solucionar problemas redes AES67.

1. Diferenciado ponto de código de serviços (DSCP) – Camada 3 QoS

DSCP é o mecanismo primário de camada 3 QoS usado no AES67. Funciona inserindo um valor de 6 bits no Tipo de Serviço (ToS) de cada pacote IP. Os interruptores de roteadores e camadas 3 podem ser configurados para examinar esta marcação DSCP e colocar pacotes na fila de prioridades apropriada. O AES67 define três valores específicos do DSCP para diferentes classes de tráfego:

  • Fluxos de áudio AES67 – DSCP 46 (EF – Encaminhamento Adiado): Esta é a marcação de prioridade mais alta, usada apenas para a carga útil de áudio. A EF garante um atraso baixo, um nervosismo baixo e uma baixa perda – muitas vezes chamado de tratamento "premium". Na prática, o tráfego de EF deve ser vigiado para evitar que qualquer fluxo único de sobrepuja a fila de prioridades.
  • Controlo e Descoberta AES67 – DSCP 56 (CS7): Controle o tráfego, como anúncios SAP e gerenciamento de conexão está marcado com o Seletor de Classe 7 para garantir que a sinalização crítica não seja bloqueada. Embora os pacotes de controle sejam pequenos, perdê-los podem impedir que os dispositivos se descubram ou mantenham uma conexão.
  • AES67 PTP (Protocolo de Tempo de Precisão) – DSCP 46 (EF) ou DSCP 44 (CS5): Os pacotes PTP carregam informações de tempo que todos os dispositivos precisam para permanecer sincronizados. Muitas implementações usam a mesma marcação EF como áudio, ou uma prioridade ligeiramente menor como CS5 para evitar interferir com os recursos de fila de áudio se forem escassos. Uma configuração comum é colocar o PTP em uma fila dedicada de prioridades estritas com uma garantia de largura de banda muito pequena, garantindo que ele seja servido antes de tudo, exceto áudio.

Os administradores de rede devem verificar que seus switches e roteadores honram essas marcações DSCP. Infelizmente, muitos switches de nível empresarial têm diferentes modelos de confiança padrão: alguns confiam apenas na Camada 2 QoS (802.1p), enquanto outros podem ser configurados para confiar na DSCP. A configuração adequada é essencial para evitar que pacotes de áudio sejam remarcados ou desclassificados para o melhor esforço. Por exemplo, um switch Cisco definido para “não confiável” em uma porta de acesso irá eliminar o campo DSCP, destruindo instantaneamente a prioridade. Sempre defina o limite de confiança para “dscp” em portas onde os terminais AES67 estão conectados.

2. IEEE 802.1Q VLAN tagging e pontos de código prioritários (PCP) – Camada 2 QoS

Na Camada 2, o AES67 ordena o uso de marcação VLAN IEE 802.1Q para fluxos de áudio. Uma tag VLAN contém um campo de ponto de código prioritário de 3 bits (PCP) que pode especificar oito níveis de prioridade (0 a 7). A norma AES67 recomenda um valor de PCP de 5 para o tráfego de áudio, que corresponde a “aplicações críticas” no mapeamento de prioridade 802.1Q. Esta marcação serve para dois propósitos:

  • Segregando tráfego de áudio: Colocando áudio em um VLAN dedicado isola-o de tempestades de transmissão, ruído multicast e outros tráfego de dados que podem causar congestionamento. Um VLAN separado também simplifica a aplicação de segurança ACLs e monitoramento de uso de largura de banda.
  • Fornecendo priorização por hop: Os switches Ethernet que não suportam DSCP ainda podem usar o valor PCP para priorizar pacotes de áudio sobre outros VLANs ou tráfego desmarcado. Mesmo quando DSCP é confiável, a prioridade Layer 2 fornece um mecanismo de retorno em interruptores mais simples.

É importante notar que a marcação VLAN sozinha não é suficiente para QoS de ponta a ponta em redes roteadas. A marcação PCP é removida quando um pacote atravessa um roteador, a menos que o switch e roteador estejam configurados para mapear a prioridade da Camada 2 para DSCP. Portanto, uma rede robusta AES67 deve ter configuração QoS consistente em ambas as camadas. Muitos engenheiros usam um mapa de políticas na interface roteada que copia PCP para DSCP, ou eles dependem do endpoint para definir DSCP corretamente, de modo que a prioridade da Camada 2 seja derivada dele.

3. Reserva de largura de banda e Controle de Admissão

Embora não seja estritamente um "mecanismo" QoS no mesmo sentido que o DSCP, o AES67 incentiva o uso de técnicas de reserva de largura de banda para evitar a sobre- inscrição de links de rede. O padrão define uma largura de banda máxima admissível para fluxos AES67 em um determinado segmento de rede, tipicamente 100 Mbps para Gigabit Ethernet para deixar a sala de comando para outro tráfego. Os engenheiros de rede podem usar protocolos como o Protocolo de Reserva de Recursos (RSVP) para solicitar dinamicamente largura de banda para fluxos de áudio, embora o RSVP não seja obrigatório em AES67. Na prática, o planejamento manual de largura de banda é muitas vezes preferido para garantir comportamento determinístico. Por exemplo, se você tiver 48 canais a 24 bits, 48 kHz, cada fluxo consome cerca de 24 Mbps (incluindo cabeçalhos).

Em um link de 1 Gbps, você poderia executar teoricamente 40 fluxos, mas políticas QoS e salas de cabeça práticas sugerem um limite de 80% de utilização para a fila de prioridade. O controle de entrada torna- se vital quando vários grupos multicast estão presentes, uma vez que um único e pode afetar muitos receptores simultaneamente.

4. Precisão do protocolo de tempo (PTP) e sua relação com QoS

A sincronização precisa do tempo é uma pedra angular da AES67. Todos os dispositivos devem sincronizar com um relógio comum usando o IEEE 1588- 2008 (PTPv2). Os pacotes PTP são críticos do tempo; se forem atrasados ou perdidos, a precisão do relógio degrada-se, levando a sub-rubricas de buffer ou sobre-runs. O QoS, portanto, aplica- se ao tráfego PTP também. O AES67 recomenda que o PTP seja marcado com o mesmo DSCP de Encaminhamento Expedido como áudio (46) ou, no mínimo, um Seletor de Classes 5 (CS5, DSCP 40). Muitas implementações do mundo real dedicam um VLAN ou grupo multicast separado para o PTP para isolá- lo de outro tráfego, reduzindo ainda mais a chance de variação de atraso.

Além disso, os interruptores que suportam relógios de limite PTP ou relógios transparentes podem corrigir para atrasos de ponte, mas estas funcionalidades requerem que o QoS funcione corretamente. Sem prioridade adequada, os pacotes PTP podem ser atrasados por filamento, que um relógio transparente compensará- incorretamente, levando a erros de sincronização.

Por que QoS não é negociável para redes de áudio profissionais

Em qualquer aplicação de áudio profissional, desde um musical da Broadway até uma transmissão de notícias ao vivo, as tolerâncias para latência, jitter e perda de pacotes são extremamente apertadas. O ouvido humano pode detectar até mesmo um único pacote perdido se resultar em um clique ou pop, e jitter de apenas alguns milissegundos pode causar distorção audível ou interromper a sincronização entre alto-falantes. Os mecanismos QoS fornecem os guardiões necessários para garantir que as redes AES67 atendam a esses requisitos exigentes. Sem QoS, uma rede que funciona perfeitamente durante um ensaio silencioso pode falhar catastróficamente durante um desempenho quando consoles de iluminação, servidores de vídeo e transferências de arquivos todos competem por largura de banda.

Orçamentos de latência em som vivo

Para o reforço de som ao vivo, a latência do fim ao fim deve normalmente ficar abaixo de 10 milissegundos, e muitas vezes muito menos. Cada hop de rede – comutador, roteador ou cabo – adiciona uma pequena quantidade de latência. Sem QoS, um estouro de dados de uma transferência de arquivos ou fluxo de vídeo pode preencher buffers de switch, fazendo com que os pacotes de áudio fiquem em fila atrás de dezenas de pacotes não- áudio. Este “bufferbloat” pode adicionar dezenas de milissegundos de atraso imprevisível, tornando o sistema inutilizável. Com as marcas DSCP e PCP adequadas, os pacotes de áudio ignoram essas filas, mantendo a latência consistente e baixa.

Em uma rede bem ajustada, a latência adicional devido à fila de áudio deve ser inferior a 100 microssegundos por hop.

Impacto da perda de pacote na Fidelidade de Áudio

O AES67 usa o Protocolo de Transporte em Tempo Real (RTP) sobre o UDP, que não retransmite pacotes perdidos. Consequentemente, qualquer perda de pacote corrompe diretamente o formato de onda de áudio. Embora alguns dispositivos de recepção possam ocultar um pequeno número de amostras perdidas consecutivas, a perda persistente de até 0,1% dos pacotes pode ser audível. O QoS evita a perda ao garantir que a rede nunca atinja um ponto em que os pacotes de áudio sejam descartados devido a congestionamento. Isto é especialmente crítico em ambientes multicasts, onde um pacote perdido poderá afetar centenas de dispositivos a jusante.

Uma única gota pode manifestar- se como um breve silêncio ou um clique em todos os canais desse grupo multicast, o que é inaceitável num cenário de transmissão ou desempenho.

Sincronização e Estabilidade do Relógio

Os dados de cronometragem PTP também são transportados sobre o UDP e são igualmente vulneráveis a atrasos e perdas. Uma rede fortemente congestionada pode fazer com que os pacotes PTP cheguem atrasados, fazendo com que os algoritmos de recuperação de tempo nos receptores de deriva. Com o tempo, esta deriva resulta em transbordamentos de buffer ou subfluxos, que se manifestam como falhas ou silêncio. Ao aplicar o generoso tratamento QoS ao tráfego PTP, os engenheiros de rede garantem que todos os dispositivos permaneçam sincronizados com precisão, muitas vezes até dentro da precisão submicrosegundo, conforme exigido pela AES67. Algumas implementações usam um perfil PTP dedicado (como SMPTE ST 2110-10) que reforça os requisitos de tempo, tornando o QoS ainda mais crítico.

Implementação de QoS em uma rede AES67 – Melhores Práticas

A implantação de uma rede AES67 com sucesso requer uma configuração cuidadosa em cada dispositivo de rede ao longo do caminho dos dados. Abaixo estão as etapas e considerações concretas para implementar QoS que atenda às recomendações AES67. Estas etapas assumem uma rede gerenciada de camada 2/3 com hardware que suporta recursos padrão de QoS. Os princípios se aplicam à Cisco, Arista, Juniper, HP e a maioria das outras famílias de switches empresariais.

Passo 1: Confie nas Marcações Certas

Os switches gerenciados modernos podem ser configurados para confiar nos valores do DSCP de pacotes recebidos. Este “limite de confiança” deve ser definido nas portas de comutação que se conectam aos terminais AES67. Se uma porta de comutação estiver configurada como “não confiável” (o padrão em muitos switches empresariais), o switch irá remarcar o valor do DSCP para zero, retirando a prioridade. Configure sempre as portas de acesso conectadas a dispositivos de áudio com (Cisco) ou comandos equivalentes em outras marcas. Para portas de tronco que se conectam a outros switches, a confiança deve ser mantida também, embora alguns administradores prefiram fazer cumprir uma política específica nesses pontos usando um mapa de políticas por porta.

Também é sábio configurar ACLs que só permitem marcas DSCP elevadas de endereços IP conhecidos de dispositivos AES67, impedindo o tráfego desonesto de reivindicar prioridade.

Passo 2: Camada de mapa 2 para camada 3 Prioridade consistentemente

Nem todos os switches inspecionam DSCP, especialmente aqueles na camada de acesso que só olham para 802.1p PCP. Para preencher o hiato, você pode criar uma política de mapeamento que converte o PCP em entrada em DSCP marcação em interfaces roteadas. Isto garante que quando um pacote deixa um limite da Camada 3, sua tag DSCP está correta. Ao sair, o DSCP pode ser traduzido de volta para PCP se necessário. Por exemplo, em um switch Cisco, você pode configurar um mapa de classe que corresponde ao PCP 5 e define o DSCP 46.

Este mapeamento deve ser aplicado a todas as interfaces onde o tráfego AES67 é esperado. Prioridade consistente de ponta é a única causa mais comum de falhas de QoS em redes de áudio.

Passo 3: Largura de banda de reserva para fluxos de áudio

Embora os fluxos AES67 sejam relativamente pequenos — uma transmissão de 48 canais a 24 bits, 48 kHz poderão consumir cerca de 24 Mbps — agregando muitos fluxos podem saturar rapidamente uma ligação de rede. Use a marcação DSCP EF para garantir uma largura de banda mínima para áudio. Muitas plataformas suportam mecanismos de fila de espera como Priority Queuing (PQ) ou Low- Latency Queuing (LLQ). O tráfego de áudio deverá ser colocado na fila de prioridade estrita, mas tenha cuidado para não subscrevê- lo: se a fila de prioridade recebe mais tráfego do que a ligação pode transportar, irão ocorrer gotas de cauda. Defina um policial para limitar o tráfego de áudio a um máximo conhecido, por exemplo, 80% da largura de banda de ligação, para evitar que tal invasão de estrelas.

Para uma ligação de 1 Gbps, que dá 800 Mbps para áudio, que é tipicamente muito mais do que suficiente, mas o policial garante que uma configuração ou falha não causa a fila de prioridade de sobrecarga.

Passo 4: Isole o PTP em um VLAN dedicado

Embora o tráfego de PTP use DSCP EF ou CS5, muitos engenheiros preferem separá- lo ainda mais colocando o PTP em um grupo multicast dedicado e VLAN. Esta prática simplifica a solução de problemas e impede que os dados de controle se misturem com a carga útil de áudio. O PTP VLAN também deve receber alta prioridade QoS, possivelmente com um policial ainda mais rigoroso para garantir que os pacotes de tempo nunca sejam atrasados por grandes fluxos de áudio multicast. Algumas redes vão tão longe quanto usando um endereço multicast PTP separado e um VLAN separado para o timing apenas, com sua própria fila de prioridades. Este isolamento também ajuda ao usar relógios de limite PTP que precisam processar mensagens de PTP sem interferências do tráfego de áudio.

Passo 5: Teste e Valide

Após a configuração, testes completos são essenciais. Ferramentas como o iPerf podem gerar tráfego de fundo sintético para carregar a rede, enquanto os próprios registros de diagnóstico do dispositivo AES67 podem relatar jitter, latência e perda de pacotes. Além disso, ferramentas de análise Ethernet livres (por exemplo, Wireshark) podem capturar marcas DSCP e confirmar que a prioridade está se propagando corretamente. Um teste de campo útil é transmitir áudio enquanto executa uma transferência de arquivos grande através do mesmo switch; se o áudio permanecer limpo, a política de QoS está funcionando. Testes mais avançados podem envolver injetar quantidades variáveis de tráfego de fundo usando um emulador de deficiência de rede para verificar a tolerância de jitter.

Sempre teste com contagem de grupos multicast de pior caso e o número máximo de canais de áudio simultâneos esperados na produção.

Considerações adicionais: Multicast e IGMP bisbilhotando

O AES67 usa normalmente o IP multicast para distribuir áudio para múltiplos receptores de forma eficiente. Embora o próprio multicast não altere as marcações QoS, ele interage com o QoS de maneiras importantes. Os interruptores com o IGMP devem ser ativados para evitar as inundações multicast em todas as portas, mas o limite de confiança do QoS ainda deve ser aplicado ao tráfego multicast. Muitos interruptores tratam o tráfego multicast de forma diferente em suas ASICs de mudança; você pode precisar ativar explicitamente o QoS para grupos multicast. Além disso, certifique- se de que o protocolo de roteamento multicast (por exemplo, PIM) não altere os valores do DSCP ao encaminhar entre VLANs ou subnets.

Alguns roteadores retiram ou remarcam o DSCP por padrão no tráfego multicast roteado, o que quebraria a prioridade de ponta a ponta.

AES67 QoS Comparado com outros protocolos de rede de áudio

AES67 não é o único padrão de áudio-over-IP – outros incluem Dante, AVB/TSN e Ravenna. Entender como o QoS difere entre eles pode ajudar os designers de sistema a escolher a plataforma certa para uma determinada aplicação.

Dante usa um esquema QoS proprietário com DSCP 46 para o áudio e DSCP 56 para o controle, muito semelhante ao AES67. No entanto, Dante também emprega um protocolo de descoberta proprietário e tempo de ligação local em vez de PTP. A implementação QoS está bem integrada no hardware da Audinate, tornando-o um pouco mais fácil de implantar, mas menos flexível em redes heterogêneas. Dante dispositivos muitas vezes requerem switches dedicados ou configuração específica para garantir que o mapeamento de filas internas está correto. Na prática, muitas redes Dante funcionam bem com as mesmas configurações de confiança DSCP como AES67.

AVB (Audio Video Bridging) / TSN (Time-Sensitive Networking) é um conjunto de padrões IEEE que inclui mecanismos QoS como a modelagem baseada em crédito e prioridade estrita. AVB requer switches compatíveis que suportam todo o kit de ferramentas TSN, incluindo 802.1Qat (Stream Reservation Protocol) e 802.1Qav (Forwarding and Queuing). Ao contrário do AES67, o AVB garante largura de banda reservando-o a priori, o que fornece comportamento determinístico mesmo em links congestionados. No entanto, os switches AVB são mais caros e menos comuns do que os switches gerenciados padrão. O AES67 pode executar através de redes AVB, mas não requer TSN, o que o torna mais acessível, mas menos determinístico em redes compartilhadas sem switches TSN.

Ravenna, desenvolvido pela ALC NetX, é muito próximo de AES67 (de fato, AES67 extraída fortemente de Ravenna). Suas recomendações QoS são quase idênticas: DSCP 46 para áudio, DSCP 56 para controle e PTP com alta prioridade. As redes Ravenna se beneficiam das mesmas práticas QoS discutidas aqui. Algumas implementações Ravenna adicionam otimizações de buffers de jitter proprietárias que podem tolerar maiores variações de atraso, mas o princípio de marcação de pacotes corretamente permanece o mesmo.

Pistácios comuns e solução de problemas QoS na AES67

Mesmo com planejamento cuidadoso, questões QoS podem surgir. As mais frequentes incluem:

  • Mudar a configuração errada da confiança: Se o dispositivo de rede não confia nas marcações DSCP do endpoint, a prioridade é perdida. Verifique as configurações de confiança em cada porta de comutação ao longo do caminho. Use ou equivalente a confirmar.
  • Políticas de filas incorretas: Alguns interruptores usam uma ordem de prioridade fixa, enquanto outros usam robin redondo ponderado (WRR). O tráfego de áudio deve ser colocado na fila de prioridade estrita (queda 4 ou 5 em muitas plataformas). Na saída, também garantir que a fila de prioridade não é superdimensionada - alocando 80% da largura de banda para áudio é um ponto de partida seguro.
  • Interferência de aplicações erradas: Qualquer dispositivo na rede pode enviar pacotes com valores DSCP elevados. Uma impressora ou servidor mal configurados pode causar o transbordamento de filas de prioridade. Use ACLs para restringir as marcações DSCP de alta prioridade aos terminais conhecidos do AES67. Considere implementar uma política DiffServ que só permite o DSCP 46 dos endereços MAC ou subredes IP de dispositivos de áudio.
  • Temporização PTP sobre VLANs: Se os pacotes PTP devem cruzar os limites do VLAN (através de um roteador ou de um interruptor de camada 3, o dispositivo deve ser PTP- consciente ou suportar a funcionalidade do relógio de limite. Caso contrário, o interruptor irá introduzir latência e jitter que o QoS sozinho não pode corrigir. Use relógios de limite transparentes ou transparentes PTP em todos os saltos de camada-3.
  • Congestão na fila de prioridades em si: Mesmo com o policiamento, uma explosão pode causar quedas de cauda dentro da fila de prioridade se o modelador for definido de forma muito agressiva. Certifique-se que o policial permite a headroom acima da contagem de pico de fluxo esperada.

Recursos externos para leituras posteriores

Para um mergulho mais profundo na AES67 e seus mecanismos QoS, recomendam-se os seguintes recursos:

Conclusão

Os mecanismos de qualidade de serviço definidos na AES67 não são apenas recomendações – eles são essenciais para fornecer áudio profissional em redes IP. Ao alavancar as marcas DSCP na Camada 3, 802.1Q etiquetas PCP na Camada 2, planejamento cuidadoso de largura de banda e tempo de PTP adequado, integradores de sistema podem construir redes que são confiáveis e escaláveis. Embora a configuração requer disciplina e uma compreensão sólida dos fundamentos de rede, o pagamento é uma infraestrutura flexível que suporta áudio de alta contagem de canais e baixa latência em praticamente qualquer ambiente Ethernet moderno. À medida que a indústria continua a se mover para fluxos de todos os IP, dominar o AES67 QoS continuará sendo uma habilidade vital para profissionais de áudio e engenheiros de rede, tanto. Validação regular, documentação completa e aderência aos padrões garantirá que mesmo as produções de transmissão ou transmissão mais exigentes sejam sem falhas.