Art-Net and sACN do the same job: they carry DMX512 channel data over an ordinary Ethernet network, so a controller can feed many universes to nodes, dimmers, media servers, and pixel drivers through one cable instead of one DMX line per universe. If you are choosing between them, the honest answer is that either will light your show, most modern gear speaks both, and the right choice depends on your network size and a couple of specific features, not on one protocol being "better". This article walks through the real differences so you can choose deliberately rather than by default.
Where the two protocols come from
Art-Net was created by Artistic Licence and first published in 1998. The specification is free to download and royalty-free to implement, but it is maintained by a single company rather than a standards body. The current version is Art-Net 4. Because it arrived early and costs nothing to implement, it became the de facto protocol in a huge number of software packages and budget nodes. We cover its history and packet structure in more depth in our Art-Net article.
sACN (streaming ACN) is an open industry standard: ANSI E1.31, developed through ESTA's Technical Standards Program, the same body behind the DMX512 and RDM standards. First ratified in 2009, revised in 2016 to add universe synchronization, current edition E1.31-2018. No single vendor controls the document. It was designed later than Art-Net, with large networked installs in mind, and it bakes in features Art-Net lacks, most importantly per-universe priority.
In practice both are stable, free to implement, and here to stay; the governance difference mainly explains the design choices below.
How they move data across the network
Both protocols send DMX data as UDP packets, Art-Net on port 6454 and sACN on port 5568. How those packets reach the nodes differs, and this is the biggest practical distinction. If terms like unicast, broadcast, and multicast are new to you, our networking terminology article covers them.
Art-Net historically broadcast its packets: every packet goes to every device on the network. Broadcast is the plug-and-play mode, with nothing to configure, but every device on the switch, including your laptop, receives every universe whether it wants it or not. Harmless at 4 universes, a real load on every network interface at 100. Since Art-Net II, controllers are expected to discover nodes with ArtPoll and then unicast each universe directly to the IP address of the node that needs it, with broadcast as a fallback. Unicast scales well, but it depends on the controller doing discovery correctly, some software still defaults to broadcast, and the address mapping must be kept current when hardware changes. Older gear may default to Art-Net's traditional 2.x.x.x addressing, although modern implementations run happily on any subnet, including a normal 192.168.x.x network.
sACN uses multicast by default. Each universe has its own multicast group address: universe 1 lives at 239.255.0.1, universe 2 at 239.255.0.2, and so on. A node that needs universe 7 subscribes to 239.255.0.7 and receives only that traffic. Nobody maintains an IP-to-universe mapping by hand: the controller transmits each universe once, and every subscriber receives it. This is why sACN scales so cleanly. sACN can also be sent unicast where needed, but multicast is the normal mode.
What multicast asks of your switches
Multicast's efficiency is not free. A basic unmanaged switch does not understand multicast subscriptions, so it floods every universe out of every port, exactly like broadcast. Your sACN network still works, but you have lost the scaling advantage.
To make multicast selective, your switches need IGMP snooping enabled, and the network needs an IGMP querier (usually a role you enable on one managed switch). With both in place, switches learn which ports subscribed to which universes and forward only what each port asked for. With snooping on but no querier, subscriptions can silently time out and output stops minutes after everything looked fine, a classic "it worked at load-in" failure. If you run managed switches, set both. If you run one unmanaged switch and a handful of universes, do not worry about any of this. Our bandwidth planning article shows how to estimate the actual load either way.
Priority: the feature Art-Net does not have
Every sACN source stamps each universe it sends with a priority from 0 to 200, default 100. When two sources transmit the same universe, a compliant receiver outputs the higher-priority source and ignores the lower one, then falls back to the lower source when the higher one stops. This is defined in the standard, so it works across brands without configuration tricks.
The classic use case is takeover: a show controller such as the S-PLAY plays back your everyday show at priority 100, and a console patched at a higher priority takes control the moment it starts transmitting, then hands back cleanly when it goes offline. No repatching, no rebooting nodes. We cover the exact setup in using sACN priority for seamless handover. Some manufacturers extend this with per-address priority, but that is a vendor extension rather than part of E1.31, so verify support on both ends before designing around it.
Art-Net has no priority field. When two Art-Net sources hit the same universe, what happens depends entirely on the receiving node: some output the most recent packet (causing a flicker fight), some offer configurable merge modes such as HTP or LTP. Merging can be done well on Art-Net (see output merging), but it is node behaviour, not protocol behaviour, and it is not a handover mechanism. If planned takeover between systems is part of your design, this single feature usually decides the question in sACN's favour.
Synchronization across universes
Neither protocol guarantees that all universes arrive at all nodes in the same frame. For conventional fixtures this never matters. For large pixel surfaces spanning many universes, unsynchronized delivery can show up as tearing, where part of an image updates a frame before the rest. Both protocols address this optionally: Art-Net has the ArtSync packet, and E1.31-2016 added universe synchronization. In both cases the controller and every node must support the mechanism, and many do not, so check the data sheets of the specific products you plan to use rather than assuming. For most rigs under a few dozen universes this feature is academic.
Universe capacity and the off-by-one trap
Capacity constrains neither protocol: Art-Net 4 addresses up to 32,768 universes through a 15-bit port-address counted from 0, and sACN addresses universes 1 through 63,999. Both are far beyond any real rig.
The difference that actually bites people is numbering. sACN universes start at 1. Art-Net's native addressing starts at 0, and different software maps its "universe 1" to Art-Net 0 or Art-Net 1 depending on the vendor. If your first universe of pixels is dark or everything is shifted by 512 channels, an off-by-one between controller and node is the first thing to check. It is a configuration quirk, not a protocol flaw, but sACN's consistent 1-based numbering means it happens less often there. If universe numbering itself is unfamiliar, start with what a DMX universe is.
RDM support
Art-Net includes extensions that tunnel RDM over the network, so a controller can discover and configure RDM fixtures through an Art-Net node's DMX ports, on nodes that implement it. Standard sACN does not carry RDM at all: E1.31 is a one-way streaming protocol. The companion standard for RDM over IP is RDMnet (ANSI E1.33), and its adoption is still limited, so do not assume it is available. If remotely readdressing fixtures over the network is part of your workflow today, this is a genuine point in Art-Net's favour, subject to your specific node and software both implementing the optional RDM extensions.
Interoperability in practice
This is rarely an either-or decision at the hardware level. ENTTEC's current eDMX nodes, such as the ODE MK3, receive both Art-Net and sACN, and the same is true of most reputable nodes on the market. Mixed systems are also common and legitimate: a media server sending sACN to pixel nodes while a console sends Art-Net to dimmers will coexist on one network without conflict, since the protocols use different ports and addressing.
The real constraint is usually software. Check what your controller actually transmits: some entry-level applications are Art-Net only, while most professional consoles and pixel mappers send both. ENTTEC's own software covers both cases: EMU outputs Art-Net, and ELM outputs Art-Net or sACN per output (see ELM output protocols). Neither uses a dongle, and licensing never gates the protocol choice, only how many universes you can output: EMU is free to download and outputs a single universe on the free tier, with paid licences (which become perpetual) unlocking up to 32 universes; ELM's installer is free to download, its licence sets the universe count, and full licences come bundled with ENTTEC pixel controllers. A small test rig runs fine on the free and starter tiers, so you can prove your network path before scaling up.
Which should you use?
| Your situation | Reasonable choice | Why |
| Small rig, one unmanaged switch, a handful of universes | Either | Traffic is light enough that broadcast or flooded multicast is irrelevant. Use whatever your software defaults to, which is often Art-Net. |
| You need RDM over the network | Art-Net | Art-Net's RDM extensions are implemented in real products; RDMnet for sACN networks is not yet widespread. Verify RDM support in your specific node. |
| Multiple sources share universes (playback plus console takeover) | sACN | Per-universe priority is in the standard and works across brands; Art-Net merging depends on each node's behaviour. |
| Large install, tens of universes or more, managed switches | sACN multicast | With IGMP snooping and a querier, each device receives only its own universes, with no unicast address bookkeeping. |
| Large universe count but only unmanaged switches | Art-Net unicast | Multicast without IGMP snooping floods like broadcast; a controller unicasting Art-Net avoids that without new switches. |
| Mixed gear from many vendors | Check, then either | Most nodes accept both; the transmitting software is usually the deciding constraint. |
Neither protocol is the winner. Art-Net earned its ubiquity by being free and early, and it remains the path of least resistance in software. sACN was designed later with large networks in mind, and its priority and multicast models are cleaner at scale, provided your switches cooperate. Choose the row above that matches your system, and know that changing your mind later is a settings change, not a hardware swap: the cabling, the nodes, and the fixtures will not care.
Once you have decided, our guide to setting up an Art-Net to DMX node walks through addressing and patching the hardware, and the same steps apply to sACN with the universe numbering caveat above. If things do not behave, start with Art-Net/sACN troubleshooting.