Erreurs de paquets Dante vs erreurs de latence : diagnostiquer la bonne panne réseau

7 min de lecture · Mis à jour le 12 octobre 2026 · Ingénieurs façade (FOH) et retours, techniciens systèmes, ingénieurs réseaux AV, opérateurs broadcast, régisseurs de production, techniciens de salle, intégrateurs et équipes audio en tournée

Distinguez les erreurs de paquets Dante des erreurs de latence, lisez les indicateurs et histogrammes de Dante Controller, remontez la chaîne physique ou temporelle, puis vérifiez une correction durable.

TL;DR — Les erreurs de paquets Dante et les erreurs de latence signalent des limites différentes. Les erreurs de paquets indiquent des paquets média corrompus entre un switch et le récepteur, et orientent généralement vers la liaison physique. Les erreurs de latence signifient que les paquets sont arrivés trop près de la date limite de lecture du récepteur, ou après celle-ci, et orientent vers le choix du tampon, la longueur du chemin, la congestion, la QoS ou la topologie. Relevez les compteurs et les histogrammes en charge, corrigez la cause, remettez à zéro une fois pour un nouveau test contrôlé, puis vérifiez l’audio réel.

L’intégrité des paquets et leur heure d’arrivée sont deux vérifications distinctes

La vue Network Status de Dante Controller résume le comportement récent des paquets et de la latence. Un chemin peut afficher un type d’erreur sans l’autre ; il faut donc diagnostiquer l’indicateur qui a réellement changé.

Indicateur	Ce que Dante Controller signale	Première frontière à inspecter
Packet Errors	Les paquets média ont été corrompus entre le switch et le récepteur	Câble, connecteur, port du switch, optique, négociation de lien
Latency orange	Les paquets sont arrivés près de la limite de latence du récepteur	Variation de chemin, charge, QoS, topologie, marge du tampon
Latency rouge	Les paquets sont arrivés après la date limite de lecture	Même chemin, plus perte audible et réglage du récepteur
Latency gris	Le périphérique n’a aucune souscription active	État de routage avant le diagnostic de performance

Le guide de surveillance de l’état du réseau Dante explique la base de monitoring complète. Ce guide traite du choix entre corruption physique et arrivée tardive.

Diagnostiquer les erreurs de paquets en remontant depuis le récepteur

Les erreurs de paquets dans Network Status indiquent des médias endommagés sur la dernière liaison vers le récepteur. Ouvrez Device View > Status et notez le compteur d’erreurs de réception, l’état de liaison, la vitesse, l’adresse et l’utilisation. Inspectez ensuite le port du switch connecté.

Travaillez une frontière à la fois :

conservez le compteur actuel et l’heure de l’incident ;
rebranchez ou remplacez le câble du point de terminaison par un câble éprouvé ;
inspectez les connecteurs, panneaux de brassage, adaptateurs, optiques et compteurs du port du switch ;
confirmez la vitesse attendue et la négociation duplex ;
ne basculez vers un port éprouvé que dans une fenêtre autorisée ;
remettez les compteurs à zéro une seule fois, reproduisez la charge complète et vérifiez que le compteur reste à zéro.

N’interprétez pas un petit nombre comme anodin. Un ancien compteur stable peut décrire un événement passé ; un compteur qui augmente pendant la coupure constitue une preuve forte. Correllez à la fois le temps et le sens.

Diagnostiquer les erreurs de latence avec l’histogramme

La latence récepteur est l’intervalle disponible pour qu’un paquet réseau aille de l’émetteur au récepteur avant la lecture. Les périphériques pris en charge exposent un histogramme pour chaque émetteur dans Device View > Latency.

Lisez-le dans cet ordre :

Setting: la latence effective appliquée à la souscription ;
Peak: l’arrivée de paquet la plus lente observée ;
Average: la zone d’arrivée normale, pas le pire cas ;
Late measurements: les observations contenant un ou plusieurs paquets au-delà de la date limite ;
Distribution: le vert bien à l’intérieur de la limite est sain, l’orange s’en approche, et le rouge la dépasse.

Les flux multicast utilisent au moins 1 ms, et certains émetteurs négocient un minimum plus élevé que la valeur par défaut configurée sur le récepteur. Lisez la valeur effective affichée pour la souscription au lieu de supposer que chaque chemin utilise le même nombre.

Décider s’il faut réparer le chemin ou augmenter le tampon

Augmenter la latence du récepteur peut être pertinent lorsque le chemin conçu comporte plus de switches, des liens plus lents ou une variation prévisible supérieure à celle que le réglage actuel autorise. Ce n’est pas un substitut à la réparation d’une corruption, d’une congestion, d’une QoS incorrecte ou d’une topologie inattendue.

Indice	Première action préférable
Les erreurs de paquets augmentent sur un seul récepteur	Réparer le câble, le connecteur, le port, l’optique ou la négociation
La latence rouge apparaît uniquement au pic de charge	Inspecter la capacité, la QoS, le multicast et les uplinks partagés
La latence orange suit un chemin plus long approuvé	Valider un réglage de latence récepteur plus élevé
Plusieurs récepteurs échouent derrière un seul switch	Inspecter l’uplink commun, les files d’attente et la topologie
Un seul émetteur est en retard vers de nombreux récepteurs	Inspecter son chemin d’accès et la frontière commune de source
Réseau propre mais réglage inférieur à ce que le périphérique/chemin prend en charge	Utiliser une latence prise en charge et reconstruire les souscriptions

Suivez le guide des réglages de latence Dante lorsqu’un changement de tampon est justifié. Modifier la latence rétablit les flux reçus et peut interrompre l’audio ; utilisez donc une fenêtre de maintenance.

Prouver la correction sous une charge représentative

Enregistrez les routes, les réglages des périphériques, les compteurs, l’histogramme et les éléments du switch.
Exécutez tout le routage du spectacle, y compris le multicast et le trafic de secours.
Reproduisez le signal affecté jusqu’à sa destination physique.
Appliquez une seule correction physique, réseau, QoS, topologie ou latence.
Remettez à zéro les compteurs ou l’histogramme concernés et notez la nouvelle heure de départ.
Répétez la même charge et tout scénario de bascule approuvé.
Vérifiez que les compteurs de paquets restent stables, que la latence reste dans la limite et que l’audio est propre.
Restaurez ou conservez l’état accepté et documentez la responsabilité.

Si la panne ne peut pas être reproduite, conservez les preuves et définissez une fenêtre de surveillance plutôt que de déclarer le succès sur un bref écran vert.

Checklist de triage des erreurs

Les indicateurs de paquets et de latence sont traités séparément.
Le récepteur, l’émetteur, la souscription et l’heure concernés sont nommés.
La vitesse du lien, les compteurs physiques et le port du switch sont vérifiés.
La latence effective, le pic, la moyenne, les mesures tardives et la distribution sont enregistrés.
La charge de production complète et les uplinks partagés sont inclus.
Une seule frontière change par test.
Les compteurs sont remis à zéro uniquement au début d’un nouveau test consigné.
L’audio réel, la récupération, le responsable et le retour arrière sont vérifiés.

FAQ

Quelle est la différence entre les erreurs de paquets Dante et les erreurs de latence ?

Les erreurs de paquets indiquent des médias corrompus près de la liaison réseau du récepteur. Les erreurs de latence indiquent que les paquets sont arrivés près de la date limite de lecture du récepteur, ou après celle-ci. Elles exigent des premiers contrôles différents.

Quelles sont les causes des erreurs de paquets dans Dante Controller ?

La frontière habituelle est le chemin physique entre le switch et le récepteur : câble, connecteur, point de brassage, optique, port ou négociation de lien. Confirmez en observant si le compteur augmente pendant l’incident.

Quelles sont les causes des erreurs de latence Dante ?

Les causes incluent un tampon récepteur trop petit, trop de sauts réseau ou des sauts trop lents, de la congestion, une QoS incorrecte, un trafic multicast inattendu, des changements de topologie ou des uplinks contraints.

Comment lire l’histogramme de latence Dante ?

Comparez la distribution avec la limite de latence effective. Les mesures vertes confortablement à l’intérieur sont saines, les mesures orange s’en approchent et les mesures rouges sont en retard. Notez aussi le pic, la moyenne et le nombre de mesures tardives.

Faut-il augmenter la latence Dante pour arrêter les coupures audio ?

Seulement après avoir vérifié le chemin physique, la capacité, la QoS, la topologie et la prise en charge par le périphérique. Un tampon plus grand convient à un chemin plus long ou plus variable valide, mais il ne doit pas masquer une corruption ou une congestion.

Intégrez la frontière de diagnostic dans la fiche technique

Consignez la route concernée, le type d’indicateur, les compteurs, l’histogramme, le chemin, le réglage, la charge de test, l’action corrective, le résultat d’acceptation, le responsable et le retour arrière dans Techrider.live. Invitez les ingénieurs systèmes et les équipes de salle à modifier la même fiche technique, enregistrez la base approuvée et consultez l’historique lorsque le chemin change.

Guides associés

Notions essentielles