Audio: Streams and Triggers

Same project, same problems, different sense. On the surface, audio distribution seems like a simple issue, or at least, simpler than the lights. The technology for distributing light cues over ethernet is clearly a bit arcane, and sadly, not terribly well documented. Sound data, however, is thrown across ethernet every day. Computers have access to not one but many well maintained, well documented, high quality audio streaming protocols. In fact, with enough work, many pre-existing data-transfer libraries can even be shoehorned into doing duty as an audio stream. With a central server and a (cheap, outdated, obsolete) computer in every room that needs sound cues, a streaming network could provide all the audio needed, directly over ethernet in tidy TCP packets. So far, everything looks pretty good.

Until we look into how those protocols work. Try opening an internet radio station, or sharing music with an Apple TV or Airport Express. In fact, try viewing a video on YouTube. There are palpable seconds between the moment the data is requested, and the time it takes to get to your ears. Of course, this is perfectly fine when your only goal is simply to hear that music, or watch that video. They will get to you, no problem, that's what those systems are meant to do, get the data from a central location, out to speakers. These protocols will all buffer and therefore they will all present a significant latency. Getting your Youtube video three seconds after you click is pretty good. Playing a sound cue three seconds late isn't.

So where to go from here? Well it's pretty clear that those streaming protocols aren't very helpful in this situation. But only because they were designed to solve a different problem. Those protocols solve the issue of how to get the data to the user, they have nothing to do with time and triggers and everything to do with pushing data around. Most of the time they are used when the device playing back the media either cannot or should not have its own copy of the media, e.g. an AirportExpress which has no memory of its own to store data on, or YouTube where copy-righted content can stay safely on the server. The issue here is getting the data to play on time, not getting the data to location. So what if the client machines, the low-end boxes distributed throughout the building, already had the audio files loaded onto them, waiting to be triggered at any moment. No waiting for data to buffer, no delay, near 0 latency. And not just triggers to play and stop, but for gain, speed and duration modification too. This way the bandwidth isn't being taken up by audio pouring through it, choking off the light cues and increasing delay. So far as I can tell this doesn't exist yet. Oh well, time to make it.

Edit: Austin just made an interesting point, this is pretty much what Apple did with their iTunes remote protocol. I have to say I am a little bit worried by how damn slow that is, and I'm hoping this will be better. Right now I'm still laying down some groundwork code/systems.

DMX over CAT5 vs DMX over CAT5 via IP

These days there are many means of distributing DMX instruction packets between devices appart from traditional 5 pin XLR cables. 5 pin has existed as an industry standard for many years, however with the changing demands of both the entertainment industry and complexity of technical theater, other solutions have emerged.

Nearly every new commercial or public construction project within the last twenty years comes prewired with three cables. Power, phone, and CAT5. The latter is of most interest. DMX instruction packet distribution over CAT5 offers several significant advantages, most notably cost and ease of use. Performing in an unorthodox space? Chances are CAT5 is already run through your venue!

Preexisting CAT5 cable can be utilized in two fassions.

Traditionally, early adopters of CAT5 simply used the cable as an inexpensive solution to long runs of 5 pin, doing a straight up electrical conversion. There is one quite glaring problem with the method. The R S-485 protocol that DMX runs on is not compatible with any TCP/IP hardware. In other words, DMX and standard ethernet based hardware are electrically incompatible, and connecting them will result in destruction of one or both pieces of hardware. The advantage of CAT5 to DMX cabling is no switching or routing hardware is needed, and the cable functions identically to a DMX run.

Since the late 1990's many companies have constructed their own TCP/IP based DMX conversion protocols. Since these protocols utilized the TCP/IP stack, the are 100% compatible with preexisting ethernet systems. One of the most widely accepted standards of TCP/IP DMX transmission is the ArtNet protocol. ArtNet can run through existing routing hardware (removing the costs of opto splitters) and distribute up to 256 individual DMX universes (256*512 =131,072 control channels) over one CAT5 cable! To make matters even better, ArtNet is a bidirectional connection, thus any ArtNet terminal can be reconfigured to work as a control module, allowing you to place your console literally anywhere with any ethernet jack.

Additionally, each lighting manufacturer maintains their own proprietary protocols for interface with their hardware. ETC, Strand, a, Pathway, MA, and Hog Ethernet protocols are entirely proprietary to the company. Often these protocols offers slight advantages over ArtNet, yet their lack of uniformity can make addition additional gear difficult.

Most hardware today (dimmer racks, intelligent fixtures, etc) come with or have options for ArtNet ethernet inputs, allowing these systems to be build inexpensively and efficiently. ArtNet nodes are available, which allow for conversion of ArtNet protocol to traditional 5pin DMX. When running an ethernet based system it is vital to stay on top of traffic over the network. It is highly recommended that you do not run 'internet' and lighting control protocol over the same wires, as it can increase network latency.

Now for the project. 30+ rooms over ethernet, cue stack for each room, one centralized time stream. Stay tuned!