ZIPP-A
| Warning | ZIPP-A is currently in the early experimental-development stage. Hardware, firmware, audio transport methods, network protocols, synchronization, configuration procedures, and specifications described on this page may change substantially during development and testing. |
ZIPP-A Audio Controller
ZIPP-A (pronounced "zippa") is the network-audio branch of the ZIPP project family.
ZIPP-A began as a solution to a relatively simple problem:
How can stereo audio be sent from a show computer through ordinary Ethernet network infrastructure to an FM transmitter located remotely in a display?
The original concept uses an ESP32 with Ethernet capability to receive digital audio through the network and an I2S stereo DAC to convert that audio back to conventional analog stereo near the transmitter.
This allows the long-distance portion of the audio path to remain digital.
As the concept developed, it became apparent that the same architecture could potentially provide distributed audio throughout Christmas, Halloween, and other interactive displays.
Project Status: Early experimental development / temporarily shelved while other ZIPP projects are developed.
Original Purpose
Many synchronized Christmas displays transmit their show audio using a small FM transmitter.
The show computer and transmitter are not always conveniently located together.
A conventional arrangement may require a long analog stereo cable:
Show Computer
|
Analog Stereo Audio
|
Long Audio Cable
|
FM Transmitter
Long analog audio cables can be inconvenient and may be susceptible to noise, ground-loop problems, signal degradation, and interference.
Ethernet may already be distributed through the display for other purposes.
ZIPP-A was conceived as a way to use that existing network infrastructure for the long-distance portion of the audio connection.
The original ZIPP-A concept is:
Show Computer
|
Digital Stereo Audio
|
Ethernet
|
Network Switch
|
Ethernet
|
ZIPP-A
|
Stereo DAC
|
Analog Stereo
|
FM Transmitter
The network switch does not process the audio as analog sound. It simply transports the network packets containing the digital audio data.
Analog audio is generated only near the transmitter.
Design Goals
Initial ZIPP-A design goals include:
- Stereo audio transport over standard Ethernet
- Ordinary Ethernet switches and cabling
- Digital transport over the long-distance portion of the audio path
- Analog stereo output near the destination
- Low-cost hardware
- Good audio quality
- Minimal configuration
- Reliable continuous playback
- Sufficient buffering to tolerate normal network timing variations
- Integration with the ZIPP project family
- Potential support for multiple audio destinations
- Potential interactive audio applications
The final audio transport protocol and firmware architecture have not yet been selected.
Initial Hardware
The initial hardware selected for ZIPP-A development consists of:
- ESP32-ETH01 Ethernet controller
- PCM5102A I2S stereo DAC
The ESP32-ETH01 provides:
- ESP32 processor
- 10/100 Ethernet interface
- Network connectivity
- I2S capability
The PCM5102A converts the digital I2S audio stream generated by the ESP32 into conventional left and right analog audio outputs.
Conceptually:
Ethernet | ESP32-ETH01 | I2S | PCM5102A | Left / Right Analog Audio
This provides the basic hardware required for a small Ethernet-to-stereo-audio receiver.
Complete ZIPP-A firmware has not yet been developed or tested.
Why Ethernet?
The original ZIPP-A application favors wired Ethernet because the audio destination is expected to remain in a fixed location near the FM transmitter.
Ethernet provides several advantages for this application:
- Reliable full-duplex communications
- High bandwidth compared with the audio data requirement
- Long cable distances
- Inexpensive CAT5/CAT5e cabling
- Inexpensive network switches
- No additional Wi-Fi airtime
- Digital transmission over the long cable run
This is particularly attractive in a large pixel display where Wi-Fi bandwidth may already be valuable for lighting-control traffic.
Digital Audio Transport
ZIPP-A does not send analog audio through the Ethernet cable.
The audio is represented digitally and transmitted as network data.
The receiving ESP32 reconstructs the audio stream and sends digital samples to the DAC using I2S.
The DAC then generates the analog stereo signal required by the amplifier, powered speakers, FM transmitter, or other audio equipment.
Conceptually:
Audio Samples
|
Network Packets
|
Ethernet
|
ESP32 Buffer
|
I2S
|
Stereo DAC
|
Analog Audio
The exact network audio format and transport protocol remain under development.
Audio Buffering
Unlike lighting-control commands, audio requires a continuous stream of samples at a stable rate.
Ethernet packets do not necessarily arrive at perfectly uniform intervals.
ZIPP-A will therefore require buffering.
Conceptually:
Incoming Network Packets
|
Buffer
|
Constant Audio Sample Rate
|
I2S
|
DAC
The buffer allows small variations in packet arrival time to occur without producing gaps in the audio.
Buffer size introduces a tradeoff.
A larger buffer can tolerate more network variation but increases audio latency.
A smaller buffer reduces latency but provides less protection against delayed packets.
The appropriate buffer size will need to be determined experimentally.
Multiple Audio Destinations
Although ZIPP-A originated as a point-to-point method of delivering stereo audio to an FM transmitter, the same architecture could potentially support multiple audio receivers.
For example:
Network Switch
/ | \
/ | \
ZIPP-A #1 ZIPP-A #2 ZIPP-A #3
| | |
FM Transmitter Speaker Speaker
Different ZIPP-A receivers might reproduce the same audio, or future implementations could allow different audio streams to be delivered to different destinations.
This creates possibilities well beyond the original FM-transmitter application.
Multiple-destination audio has not yet been implemented or tested.
Distributed Halloween Audio
Halloween displays are one potential application for distributed ZIPP-A audio.
Instead of placing all sound effects at one location, multiple ZIPP-A receivers could be distributed throughout a yard or walkthrough display.
For example:
ZIPP-A #1 - Whispering / ambient sounds ZIPP-A #2 - Scream ZIPP-A #3 - Growling / creature sounds ZIPP-A #4 - Footsteps ZIPP-A #5 - Background effects
Sounds could appear to originate from different physical locations around a visitor.
Multiple receivers could also reproduce different sounds at different times, creating a less predictable environment.
For example, a visitor might hear:
Rustling behind them
followed by:
A scream from another location
followed by:
Footsteps or another effect farther ahead
The network makes the physical location of the audio source independent of the location where the sound was generated or stored.
ZIPP-M and ZIPP-A Integration
One particularly interesting possibility is combining ZIPP-M motion sensing with distributed ZIPP-A audio.
A ZIPP-M sensor could report the location of a visitor to the ZIPP master.
The master could then trigger an appropriate sound at a nearby or deliberately distant ZIPP-A receiver.
For example:
ZIPP-M #1
Driveway Motion
|
v
ZIPP Master
|
+------> ZIPP-A #2
|
Whisper
ZIPP-M #2
Walkway Motion
|
v
ZIPP Master
|
+------> ZIPP-A #4
|
Scream
The sound does not necessarily need to originate near the sensor that detected the visitor.
For example, motion detected in front of a visitor could deliberately trigger a sound behind the visitor.
This allows the physical relationship between detection and sound location to become part of the effect.
Cross-Triggering and Event Logic
The event-processing concepts proposed for ZIPP-M could also be applied to ZIPP-A.
Possible rules could include:
ZIPP-M #1 -> Play Sound A on ZIPP-A #3
ZIPP-M #2 -> Play Sound B on ZIPP-A #1
ZIPP-M #1 AND ZIPP-M #2 -> Play Sound C
ZIPP-M #1 followed by ZIPP-M #3 -> Play Sound D behind visitor
The same motion event could also trigger lighting, relay outputs, animated props, and audio simultaneously.
For example:
Motion Event
|
+--> Lighting Effect
|
+--> ZIPP-R Prop
|
+--> ZIPP-A Scream
|
+--> Enable Next ZIPP-M Zone
This could allow the different ZIPP projects to operate as parts of one interactive display-control system.
Cross-triggering and event logic have not yet been implemented.
Randomized Sound Effects
Distributed audio also creates the possibility of randomized effects.
Instead of playing exactly the same sound every time a sensor is triggered, the system could select from a group of sounds.
For example:
Motion Detected
|
Random Selection
/ | \
/ | \
Whisper Scream Growl
The destination could potentially be randomized as well:
Motion Detected
|
Random Destination
/ | \
ZIPP-A #1 ZIPP-A #3 ZIPP-A #5
Randomizing both the sound and its physical location could make an interactive Halloween display substantially less predictable.
Randomized audio selection and routing are conceptual features and have not yet been implemented.
Christmas Display Applications
The original FM-transmitter application remains the primary initial reason for developing ZIPP-A.
However, additional Christmas applications could include:
- Remote powered speakers
- Localized audio near individual props
- Talking or singing displays
- Audio associated with specific display areas
- Indoor/outdoor audio distribution
- Multiple speaker zones
- Interactive audio effects
A ZIPP-A receiver does not necessarily need to feed an FM transmitter.
Its analog stereo output could potentially feed any suitable audio amplifier or powered speaker.
Audio Synchronization
Synchronization is particularly important when ZIPP-A is used for sequenced Christmas lighting.
The audio heard by the audience must remain synchronized with the lighting sequence.
Network transport, buffering, DAC operation, and FM transmission may each introduce some latency.
The system will therefore need to provide stable and predictable audio timing.
Absolute minimum latency is less important than:
Consistent latency.
If the delay remains stable, the show system can potentially compensate for it.
If the delay continually changes, synchronization becomes much more difficult.
Audio synchronization and latency will therefore be important parts of ZIPP-A testing.
Multiple Receiver Synchronization
If several ZIPP-A receivers reproduce the same audio within hearing distance of one another, their outputs may need to be closely synchronized.
Even relatively small timing differences can become audible as echoes or other artifacts when the same sound reaches a listener from multiple speakers.
Possible future solutions could include:
- Shared timing information
- Timestamped audio packets
- Synchronized playback buffers
- Master clock references
This problem is substantially less important when receivers intentionally reproduce different sound effects at physically separated locations.
Synchronized multi-receiver playback has not yet been developed or tested.
Relationship to DDP
ZIPP-A does not use DDP as an audio transport protocol.
DDP is appropriate for lighting channel data but is not intended to transport continuous stereo audio.
A ZIPP master may nevertheless coordinate both systems.
For example:
Show Computer
/ \
/ \
DDP Audio
| |
Lighting Data Audio Data
| |
+------ Network ------+
The final relationship between the audio transport system and the rest of the ZIPP architecture remains to be determined.
Stand-Alone Audio Effects
Some ZIPP-A applications may not require continuous audio streaming.
A future receiver could potentially store sound files locally and receive only a command telling it which sound to play.
For example:
ZIPP Master
|
"Play Scream 7"
|
ZIPP-A
|
Local Storage
|
Speaker
This approach could dramatically reduce network bandwidth for interactive Halloween effects.
It could also allow sounds to begin with predictable timing once they are stored locally.
A future ZIPP-A design might therefore support:
- Continuous streamed stereo audio
- Locally stored sound effects
- Or both
Local sound storage and triggered playback are conceptual features and have not yet been implemented.
Wired and Wireless Possibilities
The original ZIPP-A design specifically uses Ethernet.
That remains the preferred architecture for the initial FM-transmitter application.
Other applications may eventually benefit from wireless audio receivers.
However, continuous high-quality stereo audio places substantially greater demands on a wireless network than the short control messages used by ZIPP-R or ZIPP-M.
Wireless audio would therefore need to be evaluated carefully, particularly in a display already using substantial 2.4 GHz bandwidth for lighting.
For fixed audio locations, wired Ethernet may remain the simpler and more reliable solution.
Firmware
No production ZIPP-A firmware currently exists.
Future firmware development may include:
- Ethernet initialization
- Network audio reception
- Packet buffering
- I2S audio output
- PCM5102A support
- Stereo playback
- Buffer monitoring
- Packet-loss detection
- Latency measurement
- Audio synchronization
- Multiple receiver support
- Triggered sound effects
- Local audio storage
- ZIPP-M event integration
- Diagnostics and configuration
Firmware architecture will be documented as development resumes.
Current Development Status
Initial ZIPP-A hardware has been identified.
The first development platform consists of an ESP32-ETH01 and PCM5102A I2S stereo DAC.
The immediate objective is to demonstrate:
Show Computer
|
Ethernet
|
Network Switch
|
Ethernet
|
ESP32-ETH01
|
I2S
|
PCM5102A
|
Stereo Audio
|
FM Transmitter
Once reliable point-to-point stereo transport has been demonstrated, additional applications such as multiple receivers, distributed sound effects, and ZIPP-M integration can be investigated.
Development is currently temporarily shelved while other ZIPP projects are being developed.
Relationship to Other ZIPP Projects
ZIPP-A is part of the larger ZIPP project family.
Related projects include:
- ZIPP - DDP pixel control
- ZIPP-R - Distributed relay control
- ZIPP-I - Incandescent-light control
- ZIPP-M - Motion sensing and interactive control
ZIPP-A and ZIPP-M together could provide the audio and sensing portions of a distributed interactive-display system.
Combined with ZIPP-R and the original ZIPP pixel controller, the architecture could potentially coordinate:
- Pixel lighting
- Incandescent lighting
- Relay-controlled props
- Motion sensing
- Sound effects
- Distributed audio
from a common control system.
Future Development
Major areas of future ZIPP-A development include:
- Ethernet audio transport
- ESP32-ETH01 firmware
- PCM5102A I2S output
- Audio packet format
- Buffering
- Packet-loss behavior
- Latency measurement
- Christmas-show synchronization
- FM-transmitter testing
- Multiple receivers
- Receiver synchronization
- Multiple audio streams
- Locally stored sound effects
- Triggered playback
- Randomized effects
- ZIPP-M integration
- Distributed Halloween audio
- Configuration interface
- Enclosure development
Project Author
ZIPP-A is a DIY Christmas member project developed by Ernest Horning as part of the ZIPP project family.
The project is being documented during development so that design concepts, hardware experiments, test results, and design decisions can be preserved as the system evolves.