35 years later, specialists in event technology are dealing with a similar question. Art-Net or streamingACN (short sACN) ? In simple terms, both protocols have the same purpose. Transport DMX from A to B. The theoretical performance data say little about the technical differences. Art-Net advertises in the current version 4 with 32,768 possible DMX universes for the favor of the users. sACN even with almost 64,000 universes. Limits that are certainly at 99.99% So far, the events have not been significant.

Now listen to me!

In order to understand the biggest difference, the user should first deal with network technology. Not a bad idea if you want to stay longer. The transmission of Art-Net works according to the broadcast principle. So, ONE sends to ALL. sACN uses multicast. One sends to many. With broadcast and multicast transmission, the bandwidth used remains the same from about 200-250Mbit/s for 1000 universes. The difference is which part of the signal chain has to deal with it. Both variants have their basic advantages and disadvantages and require some know-how in the configuration of the network infrastructure involved. For both protocols, the user is free to choose Unicast for the transmission. That means one to one. If you choose Unicast for the transmission of the same information to several sinks, the bandwidth will add up in some places. Incidentally, not only the bandwidth but also the computational load. For me, it would be much more exhausting to tell the same thing five times than to hold a group devotion. Sounds logical, right?

The zero is the one.

The first-time user will quickly scratch their head when using Art-Net. The problem is the counting. In the first Art-Net versions, 256 universes with only two digits (rotary switches) should be described. For Art-Net creator Wayne Howell, this is an easy task. 16 subnets multiplied by 16 universes. To use only two digits one counts not decimal of 1-16 but hexadecimal of 0-9 and A-F. Once understood, this is not witchcraft.
Universe number 1 is 0:0 and Universe 256 is F:F. The real problem is supposed facilitation that some manufacturers have implemented in their Art-Net-enabled products. With a device with display, it is no problem to offer the user a simple number of 1-256 and convert it internally into hexadecimal. In the meantime, there are some variants that all describe the same thing. You can count from 0-F, 1-16 or 0-15. Of course also from 0-255 or from 1-256. This doesn't make it any easier. Problems often arise when the source and sink, or even just two technicians, count differently. You like to lie around a universe next to it. A classic example of ‘well-meaning is not equal to well-made’. With sACN, things are easier. You count from 1 high. There is no universe 0. Universe 16589 is universe 16589 everywhere.

No standard is a solution.

Another not-so-obvious but serious difference is standardization. Art-Net is protected by a copyright of Artistic Licence, but may be used without royalties. In addition to the simple implementation certainly a reason for the wide distribution. sACN, on the other hand, is described in the ANSI standard E.1.31. The American National Standards Institute, for example, also carries our long-standing DMX512-A under the standard E1.11. Those who carry out fixed installations, e.g. on cruise ships, are often bound to the execution according to ANSI E1.31 via the tender. Actually no problem. sACN is a good and robust protocol that offers further advantages. Among other things, priorities can be set at different sources for a universe. However, unlike Art-Net, sACN E1.31 does not support RDM over Ethernet to this day. With the technology called Remote Device Management, addresses can be changed via the 3-pin DMX cable from the node to the lamp and sensor information can be read. The standard E1.33 (also called RDMnet) is intended to support this in the future. However, since little is being done at this point, there is now an alternative.

With Art-Net Version 4, both protocols can be used in a kind of hybrid variant. sACN is used for signal transport. Art-Net takes over the transport of the RDM data in the background. An invitation to tender under ANSI E1.31 therefore no longer excludes the use of RDM.

All those who do not use an RDM in 2019 are welcome to continue driving Steiger. Of course, RDM cannot change burners, modes change already. The data from the sensors are also worth gold, especially in fixed installations. Those who deal with signal transport over networks in more complex environments quickly come to the conclusion that quality of service is a must. We no longer place DMX multicore, but may share an infrastructure with the colleagues from the sound and in the worst case also from the video. It must be ensured that our DMX Stream has priority over the files that are currently being copied from media server A to media server B, for example. Art-Net and sACN can only be prioritized via their respective UDP port. I miss a mechanism like the DSCP DiffServ used by Audinate in both protocols.

Another important topic in DMX over Ethernet applications is the synchronous output of data at different nodes. Here, the problems are more common in the nodes than in the network. To understand why, you have to remember how fast today's networks are and how slow DMX is. At a DMX frequency of 44Hz, the node receives a new DMX frame for a specific universe approximately every 23 milliseconds. However, the insertion delay of a network switch is measured in microseconds. The difference? factor of 1000. If you are looking for reasons for delays in a network that is not overloaded, you should start with your nodes. All nodes will have received your DMX data at the same time. At least if you think in the DMX time grid. However, it is possible that the respective nodes play the DMX at a time that differs by a few milliseconds. The reason lies, among other things, in the internal working cycle of the nodes. No one notices this in many applications. But with some others it is. My dear colleague Rocketchris Glatthor recently showed me exciting videos from a test series with many thousands of RGB pixels. There were visible delays when playing the DMX data. Art-Net offers the possibility to send an optional sync package. All DMX data is sent to the nodes and processed there. Shortly after the DMX data follows a very small sync package that commands the nodes to play the DMX frame now. Like the starting pistol at track bike races. With the Sync package, the delay of a few milliseconds can be pressed into the invisible area by a few hundred microseconds.

Closing word

There is no real war of formats.
After all, almost all nodes and consoles can handle Art-Net and sACN.
It is our task to know and use the respective strengths and weaknesses.

I think we are still far from the one patent solution for all applications at DMX over Ethernet. But even the simplest protocols are superior to a simple DMX cable. Many of today's applications would be inconceivable without the pioneering work of Wayne Howell and his colleagues.