AES67

need some clarification
using aes67 (audio over IP)
does this mean that any remote that i have with an audio output can also be a location for speakers ?

example - pi based controller left side of yard, can i plug 2 speakers in there
another pi based controller - right side of yard, plug in 2 speakers to that pi

and have them all output audio - timed together- so instead of needing more volume - i can have all the speakers low so all sides of the yard have nice low audio ?


is this what aes67 is meant for FPP ?

hmm so no one knows what AES67 does ?
which includes me - dammit

Yeah it's new in FFP10 I think. PipeWire + GStreamer, which brings multi-zone audio, AES67, and Opus RTP. Not sure how it's practical in our shows without buying more hardware. I run older RPi3bs, but keen to learn more as I'm over pulling 3.5mm cable across my yard and I've broken the cable each year to run audio to my speakers.

Ok so basically it's a way to get audio to client devices. Basically a "standard" way of doing what Pulsemesh does.

The audio is typically pre-distributed to the client, rather than streamed in real time with the lighting data. The show player sends the music file (or a stream of audio data) to the client over the network ahead of playback, and the client stores/buffers it locally.
The server then tells the client which audio track to play and the exact timestamp at which playback should begin; because the client and server share a synchronised clock, the client can start the locally stored audio at that timestamp while simultaneously executing the lighting sequence. This means a temporary network delay or jitter during the show doesn't make the music and lights drift apart—the network is primarily delivering data and timing information, while the client handles the actual playback locally.
In our scenario, the show player acts as the master clock and show controller, with its time accurately syncrhonised by something such as GPS/PPS/PTP. When a sequence starts, the server doesn't simply tell each client "start now". It also doesnt "stream" like a typical web radio. Instead, it tells them something like "this sequence starts at 8:30:00.000" - a very precise, synchronised time. The clients can receive that instruction several seconds early, along with the required sequence/music, and then use their own synchronised clocks to determine exactly when playback should begin.
The important part is therefore clock synchronisation, not network latency. If every client knows the same absolute time to within, say, a few milliseconds, they can independently start the music and lighting sequence at the same timestamp. Even if one controller receives the start command 100 ms later than another, it simply waits until the agreed start time. For a display, this means multiple streamers around the property can keep the audio locked to the same timeline, rather than relying on a network packet arriving at precisely the right moment.