Qu'est-ce que sACN ? Explication de l'ANSI E1.31

Ce qu'est réellement sACN

sACN signifie une norme avec un nom beaucoup plus long : ANSI E1.31-2025, Technologie de divertissement, protocole de streaming léger pour le transport de DMX512 utilisant ACN. ACN fait référence à l'Architecture for Control Networks, ANSI E1.17, dont E1.31 emprunte le format de paquet.

Une petite curiosité à connaître, car cela trompe les gens qui écrivent à ce sujet : l'abréviation "sACN" n'apparaît jamais dans la norme elle-même. L'ESTA l'utilise de manière informelle dans ses propres bulletins ("également connu sous le nom de sACN"), et tout le monde dans l'industrie le dit, mais vous ne le trouverez pas, ni l'expansion "Streaming ACN", écrite dans le document publié. Si vous voulez être précis, appelez-le ANSI E1.31 et notez que sACN est l'abréviation courante.

La norme est publiée par le programme de normes techniques de l'ESTA, le même organisme derrière DMX512 (E1.11) et RDM (E1.20). C'est une norme nationale américaine ouverte : tout le monde peut la télécharger, et tout le monde peut l'implémenter sans frais de licence. Cette ouverture est la principale raison pour laquelle sACN s'est répandu si rapidement à travers les consoles, les nœuds, les serveurs multimédias et les logiciels.

Ce qu'elle fait est étroit et délibéré. Elle prend les 512 emplacements d'un univers DMX, les enveloppe dans un paquet UDP avec quelques champs supplémentaires, et les diffuse sur un réseau IP. Elle ne configure pas les appareils, ne découvre pas les appareils, et ne transporte pas de RDM. Elle déplace rapidement les niveaux d'éclairage vers de nombreux endroits à la fois.

Comment sACN voyage : multicast et port 5568

sACN fonctionne sur UDP sur le port 5568. Ce port est correctement enregistré auprès de l'IANA, sous le nom de service sdt (Session Data Transport), ce qui est un petit mais réel signe de la maturité de la norme.

La partie astucieuse est l'adressage. sACN utilise normalement le multicast, et le numéro d'univers est directement intégré dans l'adresse multicast :

• Les deux premiers octets sont toujours 239.255.
• Le troisième octet est le high byte du numéro d'univers.
• Le quatrième octet est le low byte.

Donc l'univers 1 est 239.255.0.1, l'univers 2 est 239.255.0.2, et l'univers 300 est 239.255.1.44. Il existe également une forme IPv6, dans la plage FF18::83:00:00:00 et plus, construite de la même manière à partir des deux derniers octets.

Parce que l'adresse est dérivée de l'univers, un récepteur n'a pas besoin de savoir d'où viennent les données. Il rejoint simplement le groupe multicast pour les univers qui l'intéressent, et le réseau ne livre que ceux-ci. C'est pourquoi un grand rig peut fonctionner sur un seul câble sans que chaque nœud soit configuré individuellement.

Une subtilité que la norme précise : l'univers est identifié par le numéro à l'intérieur du paquet, et non par l'adresse sur laquelle il est arrivé. Un récepteur ne doit jamais supposer que les deux sont d'accord.

Le unicast est également autorisé, et un récepteur doit accepter sACN envoyé directement à sa propre adresse IP. Le hic est clairement énoncé dans la norme : sACN ne définit aucun moyen de découvrir ces adresses, donc avec le unicast, vous devez configurer les adresses IP de destination manuellement. Cela va pour deux nœuds et est douloureux pour vingt.

Univers : combien et quels numéros sont interdits

La norme permet des numéros d'univers de 1 à 63999. L'univers 0 est réservé et ne doit pas être utilisé, tout comme tout ce qui va de 64000 à 65535, avec une exception : l'univers 64214 est réservé pour la découverte d'univers.

Deux autres règles piègent les gens :

• Les 256 premières adresses multicast IPv4, de 239.255.255.0 à 239.255.255.255, sont réservées par l'IANA à d'autres fins, donc les appareils E1.31 ne doivent pas transmettre dessus. Si ces univers sont jamais utilisés, ils doivent être envoyés en unicast.
• Les numéros sACN commencent à 1, tout comme DMXDesktop, donc le numéro que vous définissez est le numéro qui sort. Art-Net est l'exception, car il commence à 0.

La découverte dans sACN est limitée et il est important de comprendre cela avant de chercher une fonctionnalité qui n'existe pas. Les sources annoncent quels univers elles transmettent en envoyant une liste sur l'univers 64214 toutes les 10 secondes. Cela permet à un outil de surveillance de montrer ce qui est sur le réseau sans rejoindre chaque groupe multicast. Mais il n'y a aucune découverte de dispositif dans sACN : rien ne vous dit quels nœuds existent, comment ils s'appellent ou comment les configurer. Si vous voulez cela, vous avez besoin d'Art-Net ou de RDMnet.

Priorité : comment sACN décide quelle source gagne

C'est la fonctionnalité qui rend sACN attrayant pour tout ce qui doit continuer à fonctionner. Chaque paquet de données sACN porte une valeur de priorité de 0 à 200. Une source qui ne prend pas en charge la priorité variable doit envoyer 100, c'est pourquoi 100 est la valeur par défaut presque partout.

La règle est simple : pour un univers donné, un récepteur prenant des données de plusieurs sources considère la priorité la plus élevée comme les données définitives. Les nombres plus élevés gagnent. Ainsi, une console de secours envoyant à une priorité de 90 reste silencieuse sous une console principale à 100, et prend le relais dès que la console principale s'arrête. Pas de commutation, pas de patching, pas d'intervention de l'opérateur.

La priorité s'applique par univers, pas par canal. La priorité par slot est un mécanisme distinct que l'E1.31 mentionne mais ne définit pas.

Ce qui se passe lorsque deux sources sont à égalité à la priorité la plus élevée est là où les implémentations diffèrent, et la norme est honnête à ce sujet. Elle définit deux comportements, fusionner (combinant les données, généralement la plus élevée prend le pas par slot) et arbitrage (choisir une source), et exige que chaque dispositif documente lequel il utilise, combien de sources il peut gérer et ce qu'il fait lorsque cette limite est dépassée. Elle ne mandate pas d'algorithme.

Elle donne un avertissement fort, et c'est une bonne règle pour la conception de rig : les concepteurs sont "très fortement découragés" d'utiliser des algorithmes qui produisent des résultats différents à partir du même ensemble de sources à différentes occasions, comme accepter la première source qui apparaît. Le résultat dépend alors de l'ordre dans lequel les choses ont été allumées, ce qui est la dernière chose que vous voulez le jour d'un spectacle.

Dans DMXDesktop, la priorité est définie par univers, de 1 à 200, par défaut à 100.

Que se passe-t-il lorsque les données s'arrêtent

sACN fonctionne sur UDP, ce que la norme déclare clairement n'offre aucune reconnaissance et aucune garantie que les paquets arrivent. Donc, la question intéressante n'est pas de savoir si les paquets se perdent, mais ce qu'un récepteur fait face au silence.

Trois règles régissent cela :

• Délai d'expiration de perte de données : 2,5 secondes. Si un récepteur n'entend rien d'une source sur un univers pendant 2,5 secondes, cette source et cet univers sont considérés comme déconnectés. Dans la révision de 2025, cela compte uniquement les paquets de données, donc une source envoyant toujours des paquets de synchronisation ou de découverte, mais aucune donnée, expirera également.
• Keep-alive : toutes les 800 à 1000 millisecondes. Une source qui n'a rien de nouveau à dire n'a pas besoin de continuer à inonder le réseau. Elle envoie trois paquets identiques, puis revient à un seul paquet keep-alive environ une fois par seconde, ce qui est suffisant pour rester dans la fenêtre de 2,5 secondes.
• Arrêt propre : le drapeau Stream_Terminated. Plutôt que de simplement se taire et laisser les récepteurs attendre la fin du délai d'expiration, une source qui a terminé définit un drapeau dans trois derniers paquets. Les récepteurs considèrent cela comme une déconnexion immédiate et intentionnelle plutôt qu'un défaut.

Voici la partie que presque tout le monde se trompe. Demandez à une salle de personnes travaillant dans l'éclairage ce qu'un nœud devrait faire lorsque les données s'arrêtent, et la plupart diront qu'il maintient le dernier état. La norme dit le contraire : une passerelle doit fournir un mode où, en cas de perte de données de toutes les sources d'un univers, elle arrête immédiatement de transmettre DMX512. Le maintien du dernier état est autorisé comme mode supplémentaire, mais pas comme le mode requis. Si votre rig s'éteint lorsque l'ordinateur portable se met en veille, c'est un comportement conforme, pas un défaut, et la solution est de configurer le nœud, pas de blâmer le logiciel.

Synchronisation, données de prévisualisation et les drapeaux d'option

Chaque paquet sACN porte un petit champ d'options avec trois drapeaux définis, et ils expliquent plusieurs comportements que vous avez peut-être vus sans savoir pourquoi.

• Preview_Data. Les données marquées avec ce drapeau sont destinées aux prévisualisations de visualiseurs et de serveurs multimédias et ne doivent pas entraîner de sortie en direct. C'est ainsi qu'un designer peut exécuter un flux de prévisualisation sur le même réseau sans éclairer la pièce.
• Stream_Terminated. L'arrêt propre décrit ci-dessus.
• Force_Synchronization. Contrôle ce qu'un récepteur synchronisé fait si la synchronisation est perdue : geler jusqu'à ce qu'elle revienne, ou continuer à se mettre à jour avec de nouveaux paquets.

La synchronisation des univers elle-même existe pour les cas où plusieurs univers doivent changer en même instant, comme les panneaux LED, les serveurs multimédias et les gradateurs rapides, où quelques millisecondes de décalage sont visibles. La source décide : elle met une adresse de synchronisation dans ses paquets de données, et les récepteurs conservent ces données jusqu'à ce que le paquet de synchronisation correspondant arrive.

Deux notes pratiques. Le support de la synchronisation est optionnel pour les récepteurs, tandis que les paquets de données et de découverte ne le sont pas, donc vous ne pouvez pas supposer qu'un nœud l'implémente. Et DMXDesktop n'utilise actuellement pas de paquets de synchronisation : il diffuse des paquets de données normalement, ce qui est ce sur quoi la grande majorité des rigs fonctionnent.

Ce dont votre réseau a besoin

sACN est peu exigeant, mais le multicast a quelques exigences qui expliquent discrètement la plupart des histoires "ça fonctionne à mon bureau mais pas sur le lieu".

• Support IGMP. La norme exige que les récepteurs prennent en charge IGMP version 2 sur IPv4 (ou MLD version 1 sur IPv6). C'est ainsi qu'un dispositif indique au réseau quels groupes multicast il souhaite. Sur un petit switch non géré, tout est inondé à chaque port et cela fonctionne simplement. Sur un réseau géré plus grand, vous souhaitez que IGMP snooping soit configuré correctement, avec un interrogeur présent, sinon le trafic sera soit inondé partout, soit complètement supprimé.
• Filaires, pas sans fil. Le multicast sur WiFi est livré à des débits de données faibles et est facilement perturbé. Utilisez-le pour une tablette de contrôle à distance, pas pour un chemin de données d'éclairage.
• Règles de pare-feu. Le port UDP 5568 entrant doit être ouvert sur toute machine recevant sACN, et sur Windows, l'interface doit être celle que vous pensez qu'elle est. Les ordinateurs portables avec plusieurs adaptateurs, y compris des adaptateurs virtuels provenant de logiciels VPN, envoient fréquemment à partir de la mauvaise interface.
• Taux de rafraîchissement. La norme dit que les sources ne doivent pas dépasser le taux de rafraîchissement maximum DMX512, que l'E1.11 fixe à 44 mises à jour par seconde pour un paquet complet de 513 slots, à moins que l'utilisateur n'active délibérément des taux plus élevés sur un univers sans passerelle DMX. DMXDesktop sort à 40 Hz par défaut et peut être réglé entre 10 et 44 Hz.

sACN, Art-Net et RDM : ce que sACN ne fait pas

Deux questions se posent constamment, et les deux ont des réponses claires.

sACN transporte-t-il RDM ? Non. L'E1.31 ne définit aucun mécanisme pour RDM, donc aucun produit ne peut offrir RDM sur sACN, quelle que soit sa commercialisation. RDM sur un réseau est une norme différente, RDMnet (ANSI E1.33). RDM sur Art-Net existe également, mais c'est une extension propre à Artistic Licence plutôt qu'une norme ESTA. Dans DMXDesktop, RDM fonctionne sur des interfaces USB et sur Art-Net.

sACN est-il meilleur qu'Art-Net ? Ils résolvent des problèmes qui se chevauchent de manière différente. sACN a la priorité, l'adressage multicast et une norme formelle derrière lui. Art-Net a la découverte de dispositifs, la configuration de nœuds et RDM. De nombreux rigs utilisent les deux en même temps, ce que prévoit exactement Art-Net 4. Il existe une comparaison complète côte à côte dans le guide Art-Net vs sACN.

Problèmes courants de sACN

Presque chaque défaut sACN est l'un de ceux-ci.