sACN vs Art-Net: Which Fits Your Show?

sACN and Art-Net do the same job — they put DMX512 universes on Ethernet — so the choice is not about capability. It is about arbitration, network ownership, and what your nodes already speak. Both carry 512-channel universes. sACN normally sends each universe to its own multicast group and stamps every data packet with a priority from 0 to 200, so a building system can override a console. Art-Net 4 sends the same data to UDP port 6454, gives you 32,767 usable port-addresses (0 deprecated), and lets a node merge two controllers without ranking them. Pick sACN when a managed network and priority-based takeover are part of the design. Pick Art-Net when the rig, the crew and the console ecosystem already speak it. PILEDS builds Art-Net controllers and decoders, so the section on where Art-Net genuinely wins is not there to be balanced theater. If your real question is copper DMX versus Ethernet, the DMX512 vs Art-Net decision guide covers that fork instead.

sACN vs Art-Net at a glance

Two rows in that table decide most projects, and neither is the universe count. The first is priority: it is the one capability sACN has that ArtDmx has no field for. The second is discovery, and it runs the other way: Art-Net can tell you what is on the network and re-address it, while sACN can tell you which universes are active and nothing more. Everything else — packet rate, cable, universe ceiling — rarely changes an answer.

What sACN actually specifies — and what it leaves to you

sACN stands for streaming ACN, a subset of the Architecture for Control Networks suite, and it exists to carry DMX512-A (ANSI E1.11) inside UDP packets. ESTA publishes it as ANSI E1.31, and the current edition on ESTA's published standards list is E1.31-2025.

The technical details below come from the E1.31 specification text — the 2016 edition in full, whose fields here still match the current standard; the 2025 revision adds IPv6, not covered here.

The universe is a 16-bit field with a valid range of 1 to 63,999; zero and the values from 64,000 to 65,535 are reserved, with 64,214 used for Universe Discovery. Each universe maps to its own multicast address by placing the universe number in the last two bytes of the address, so universe 1 is 239.255.0.1 and universe 1,000 is 239.255.3.232. The top 256 addresses in that range are reserved by IANA and cannot be used for streaming. Traffic goes to UDP port 5568.

A level packet carries the 512 slot values, a sequence number for detecting duplicates and out-of-order arrivals, a synchronization address, and a priority byte. The priority is the part that matters commercially: 0 to 200, default 100, and a receiver is expected to use the levels from the highest-priority source even when that source's levels are lower than a rival's (ETC's explanation is the clearest write-up of the merge rules). If two sources sit at the same priority, the receiver merges them highest-takes-precedence, address by address.

What E1.31 does not give you is a way to configure the far end. It defines a Universe Discovery packet so a source can advertise which universes it is transmitting, which is useful for monitoring, but there is no equivalent of "change this node's universe to 47 from the console". Commissioning is local: you set the universe at the node, or accept what the integrator left behind. For a permanent installation that is a paperwork problem. For a touring rig it is a load-in problem, and it is the honest reason many rental houses never moved off Art-Net.

None of this changes at the pixel end. Whether a run speaks sACN or Art-Net, the driver IC on the strip still decides how channels map to LEDs, which is the subject of our addressable LED driver IC and protocol guide.

What Art-Net 4 actually specifies

Art-Net is owned by Artistic Licence and published openly. The official Art-Net site states the terms plainly: the protocol is free to implement on a royalty-free basis, any product that implements it needs an OEM code, and the user guide must carry the credit line. That is a formality, not a cost, but it explains why a product is or is not an Art-Net implementation.

The Art-Net 4 specification (the revision in front of me is dated October 2025) defines a 15-bit Port-Address built from a 7-bit Net, a 4-bit Sub-Net and a 4-bit Universe. The valid range is 1 to 32,767, and Port-Address 0 is deprecated specifically to improve compatibility with sACN. Traffic goes to UDP port 6454, written as 0x1936 throughout the document. Art-Net carries DMX512-A and RDM (ANSI E1.20), and adds ArtSync for frame-accurate output across ports.

Discovery is where Art-Net pulls ahead operationally. A controller broadcasts an ArtPoll to the directed broadcast address every 2.5 to 3 seconds, and every node answers with an ArtPollReply carrying its IP address, its port-addresses and its health bits. If a node does not answer within 3 seconds, the controller treats it as disconnected. ArtAddress then lets a controller rewrite a node's port-addresses and merge mode remotely. In a 40-node rig that is the difference between a patch sheet and two hours on a truss with a laptop.

The 32,767 ceiling is theoretical; the spec's planning table for unicast traffic is the useful number: about 40 universes on 10BaseT, 400 on 100BaseT and 4,000-plus on Gigabit. The network, not the address space, sets that limit.

The difference that actually bites: multicast, broadcast and unicast

sACN is a multicast protocol by design. One source, one packet per universe, and any number of receivers that have joined that universe's group. On a managed switch with IGMP snooping enabled, the switch learns which ports have joined which group and forwards accordingly, so a 60-universe rig does not send 60 universes down every cable. On an unmanaged switch, multicast is flooded to every port and each device decides whether to act on it — the same behavior as broadcast, with none of the pruning (ETC's network definitions set this out plainly).

That explains most of the support threads on this topic. A designer commissions sACN on a dumb switch, it works at 12 universes, and it falls over at 60. Nothing is broken; the network was never doing what the protocol assumed. The fix is IGMP snooping plus a querier on the VLAN — and someone who understands why the querier has to exist.

Art-Net's reputation for broadcasting is half earned. Show data can be unicast: the specification allows a controller to send ArtDmx directly to a node's IP address, and it mandates unicast for ArtPollReply and ArtRdm to keep very large systems scalable. What remains broadcast is discovery — that ArtPoll heartbeat to the directed broadcast address every few seconds. So the accurate statement is: Art-Net can run its show traffic as unicast but keeps a broadcast heartbeat; sACN multicasts by default and relies on the switch to prune it.

Which is easier depends entirely on who owns the network. On an IT-managed VLAN, sACN's multicast is an advantage because IGMP is a tool the network team already uses. On a flat rental network with an unmanaged switch, Art-Net's unicast show traffic plus a small broadcast heartbeat is usually the quieter option, and the one that survives a switch the venue supplied.

The switch, not the console, is where this decision is enforced: IGMP snooping and a querier on one side, unregistered multicast flooding on the other.

Priority: the one place sACN is structurally ahead

Priority is what Art-Net's own data stream lacks, and it is worth understanding precisely rather than as a slogan.

In sACN, every level packet carries a priority between 0 and 200. A receiver that supports multiple sources uses the levels from the highest-priority source for the whole universe, even if those levels are lower than what a lower-priority source is sending. Two sources at the same priority merge highest-takes-precedence. Some consoles and gateways go further with per-address priority, sent as a separate packet with start code 0xDD, which allows address 30 at priority 97 while address 31 sits at 126. E1.31 does not require sources or receivers to implement per-address priority, so treat it as a feature to verify, not a standard to assume.

The practical case is a building. An architectural control system holds the facade at a warm white at priority 100. A show console takes over at 150 for twenty minutes, and when it releases, the facade returns to the architectural state without anyone touching a fader. Reverse the priorities and the show can never be overridden by a well-meaning facilities manager.

Art-Net resolves conflicts differently. A node merges two sources per port, highest-takes-precedence by default, or latest-takes-precedence if the controller sends the command. The specification sets a 10-second hold: if one source stops, its last levels stay in the merge buffer for ten seconds, and if it has not returned the node exits merge mode. If both sources fail, the output holds the last merge result. That is a deliberate failover mechanism, and for a backup console following a primary it works well. What it cannot do is express "this source outranks that one regardless of level" — the node has no field to carry that intent.

If the building has a facilities team and the show has a guest operator, you need priority. If the same crew patches the same rig every week, you need discovery.

Two limits on that advantage. First, what E1.31 leaves optional is the merge algorithm, not multiple sources: a receiver must handle them somehow and declare its sources-exceeded resolution, and first-arrival resolution is discouraged — though cheap nodes often ship it. Second, priority solves arbitration, not takeover policy: someone still has to decide which system holds 150 and document it, or the next engineer will "fix" the patch.

Discovery and addressing: polling versus counting

Art-Net's addressing model is three fields, and sACN's is one number. That difference produces two very different failure signatures.

Art-Net's model is more precise but easier to get wrong by one. Software often counts universes from 1 while the wire carries Net, Sub-Net and Universe separately, and a node configured one step off responds to nothing. The diagnosis is mechanical: compare raw Net, Sub-Net and Universe values in the node, not the friendly labels. ArtAddress can fix it remotely if the node is reachable; ArtPollReply tells you what it currently thinks it is.

sACN's model is simpler to hand over and fails more quietly. A node set to universe 101 while the console sends 100 has joined a multicast group nobody is talking to. There is no error, no warning, no partial output: the pixels are dark, and the console shows levels going out. Universe Discovery can help you see which universes are actually on the wire, which is why a monitor such as sACNView earns its place in a commissioning kit.

The operational summary: Art-Net gives you more instrumentation and remote configuration, at the cost of a three-field address that invites off-by-one errors. sACN gives you a single number that is hard to misread, at the cost of commissioning each node where it hangs.

A gateway is where the addressing decision becomes physical: the Ethernet side carries universes, the XLR side carries DMX512 to the fixtures.

How many universes actually fit on one link

Start with the invariant. A universe is 512 channels in both protocols. At three channels per pixel that is 170 RGB pixels; at four channels, 128 RGBW pixels. Neither protocol changes that arithmetic, and any comparison table implying otherwise is wrong.

Then do the bandwidth sum. A full sACN data packet is roughly 638 bytes at the E1.31 layer; with UDP, IP and Ethernet headers, about 680 bytes on the wire. At the 44 Hz refresh a DMX512-rate stream implies, one universe costs about 30 kB/s, or 0.24 Mbit/s. Art-Net's ArtDmx packet is smaller, so its per-universe load is lower still, around 0.2 Mbit/s. Forty universes is under 10 Mbit/s; a Gigabit link does not notice them.

So the 63,999 versus 32,767 question is almost never the binding constraint. What binds in practice is:

• Port count on the node. Sixteen outputs at 512 channels each is 16 universes before you have started multiplying by pixel density.
• Switch behavior. A managed switch with IGMP snooping passes 60 universes cleanly; an unmanaged one floods them everywhere and the weakest device sets the ceiling.
• Node processing. A gateway asked to output 16 universes at 44 Hz is doing real work; check its rating rather than assuming.
• Wi-Fi in the path. Fine for a data hop, hostile as a streaming backbone.

If you want the arithmetic done for a specific rig, the controller capacity calculator takes pixel count and layout and returns the port and universe budget.

Large pixel installations are where universe counts stop being theoretical — and where the transport starts to constrain the network design rather than the fixtures.

Which protocol for which job

A studio sits between the cases: a fixed network, but a rig rebuilt for every production.

The pattern is not "newer wins". It is that sACN rewards a network you control and Art-Net rewards a network you inherit. A rental house inherits a different switch every week; a venue owns the same one for a decade. The permanent-install side of that is covered in our theme park and attraction lighting work, where the control network has to survive a decade of facilities staff rather than a season of load-ins.

There is also a case for Art-Net that has nothing to do with protocol design: the ecosystem. The official site counts more than 500 manufacturers implementing it, and in practice it shows up as a node that works with a console nobody expected. If a rig has to be repatchable by a freelancer at 6 p.m., that breadth is worth more than a priority field. Our stage and touring pixel LED guide covers the fixture side of the same rig.

Once the protocol decision is made, the rehearsal checklist for pixel fixtures is the list to run before the first show. Most problems blamed on a protocol on opening night are patching problems a rehearsal would have caught.

Failure modes both protocols share

Both protocols number their packets, and receivers discard out-of-order or duplicate frames rather than replaying them. A lost packet usually shows up as a single stale frame, not a visible dropout. A visible dropout is more often a stall of tens of milliseconds than one missing packet, which points at the network or the node.

Treat a wireless hop as a separate system with its own failure modes; the wireless DMX link discussion covers where that trade is acceptable.

What this means when you specify the node

The protocol printed on a controller is a line item, not a family trait. A box described as an "Art-Net controller" is not automatically an sACN receiver, and the reverse is just as true. Ask for the protocol list in writing, and ask which consoles it has been tested against — not which ones it is "compatible with".

That distinction matters for our own range too. The PI-1616A 16-port Art-Net controller takes Art-Net in and outputs DMX512 or SPI on 16 ports, up to 512 channels per DMX port (about 170 RGB pixels in 3-channel mode) or 1,024 pixels per port over SPI.

The 8-port and 12-port units in our controller and decoder range follow the same pattern. sACN support is confirmed per model at quotation rather than assumed across the range, because the honest answer for most manufacturers is that the protocol stack is a firmware decision, not a chassis decision. Anyone who tells you every Art-Net box in their catalog speaks sACN has either done the integration work or not checked.

Read a controller page for the protocol line first, then the port count: the chassis tells you the format, the input-signal row tells you what it will actually receive.

Three questions will settle a supplier conversation faster than a datasheet:

1. Which protocols does this exact model receive, and in which firmware version?
2. What happens at the output when the control source disappears — hold, blackout, or last look?
3. Does it merge multiple sources, and can it rank them?

If you are specifying a run with a known protocol and universe count, send the pixel count, the protocol and the zone layout to our team and we will come back with a port map and the decoder configuration that matches it.

sACN vs Art-Net FAQ

What is sACN in one sentence? sACN is ANSI E1.31, a standard from ESTA that carries DMX512-A universes over UDP, usually as multicast on port 5568, with a priority field that lets one source override another.

Is sACN better than Art-Net? Not in general. sACN has priority arbitration and a standards body behind it; Art-Net has broader device support and a discovery protocol that can re-address nodes remotely. Pick by the network you control and the hardware you own, not by which one sounds more modern.

Does sACN work on an unmanaged switch? It runs, but every universe is flooded to every port, which is exactly the behavior IGMP snooping exists to prevent. Small rigs get away with it; larger ones develop flicker that looks like a fixture fault.

Which one is faster? Neither, in any way you will notice. Both stream at DMX512 rates around 44 Hz. One universe costs about 0.24 Mbit/s in sACN and 0.2 Mbit/s in Art-Net, because the ArtDmx packet is smaller.

Can one rig run both? Yes, and large estates often do: sACN for the permanently installed layer, Art-Net for the touring layer, with gateways that bridge the two. Specify the bridge deliberately: it should present each protocol natively, not translate through a fixed universe offset.