AES67 just got dragged out of the broadcast machine room and onto a cheap embedded board. That matters because networked audio has spent years pretending to be open while practically belonging to dedicated Dante silicon, Linux endpoints, boutique interface boxes, and the kind of procurement ritual where a switch configuration becomes a religious text.
The new artifact is concrete: Espressif published a technical writeup of AES67 audio-over-IP on the ESP32-P4, backed by the DatanoiseTV/aes67-esp32p4 component. It implements an AES67/RAVENNA-compatible endpoint on ESP32-P4, using PTP clock sync, RTP audio packets, SAP/SDP discovery, I2S DMA playback, and a driver-level receive path that deliberately bypasses the normal socket stack for audio frames.
That last part is the tell. This is not “stream some audio over Wi-Fi” hobby sludge. AES67 is uncompressed PCM over IP. It needs the devices to agree on time tightly enough that independent endpoints do not drift, smear, click, or slowly become a Steve Reich phase piece against their will. The protocol stack is boring in the way all serious infrastructure is boring: RTP carries samples, SDP describes sessions, SAP announces them, QoS keeps the traffic civilized, and PTP, IEEE 1588, keeps the clocks honest.
The ESP32-P4 is only plausible here because it has the specific ugly hardware feature you cannot fake: an Ethernet MAC with IEEE 1588 hardware timestamping. Espressif’s post says this plainly. Software timestamps are polluted by interrupts, scheduling, and wishful thinking. Hardware timestamps catch sync packets at the MAC boundary, before the operating system can wander in wearing clown shoes.
The implementation ports the NuttX ptpd daemon onto ESP-IDF clock abstractions, then projects RTP time from the disciplined PTP time with the simple relation rtp_ts = ptp_time_ns * sample_rate / 1e9. That equation is the whole religion compressed into one line: audio is only networkable if time becomes a shared material.
The more interesting engineering decision is the fast receive path. The component hooks into the Ethernet driver before lwIP, checks frames for IPv4 UDP multicast RTP on port 5004, converts L16, L24, L32, or AM824 payloads to int32, and writes them straight into the playout buffer. Non-audio frames go back to lwIP for DHCP, web UI, and other civilized nonsense. Audio packets take the alley.
That is the right design. General network stacks are amazing until you ask them to behave like a digital audio clock. Then every copy, queue, allocation, and scheduler hiccup becomes audible. The repo’s architecture is refreshingly literal: aes67_ptp for clock synchronization, aes67_rtp for per-stream jitter buffers, aes67_audio for I2S DMA, aes67_convert for IRAM sample conversion, plus SAP, SDP, and mDNS glue for discovery. No huge framework cathedral, just the grim little plumbing needed to make the samples arrive on time.
The measured numbers are spicy. The repo reports, at 48 kHz, total end-to-end latency around 0.7 ms with 0.125 ms packet time, 1.0 ms with 0.333 ms packets, 1.7 ms with 1 ms packets, and 2.7 ms with 4 ms packets. The best-case breakdown is roughly 0.125 ms source packet buffering, 0.1 ms LAN, 0.1 ms parse and convert in the L2 hook, 0.06 ms stream buffer, and 0.33 ms for a two-descriptor DMA ring.
The important number is not the 0.7 ms flex. The important number is the 0.33 ms DMA floor. The bottleneck is not Ethernet. It is the smallest audio chunk the CPU and DMA machinery can reliably service under load. That is exactly where embedded audio gets real: not in protocol diagrams, but in the size of the buffer you can survive without clicks.
There are limits, and they are not cosmetic. The component currently targets 44.1 and 48 kHz, not 96 or 192 kHz. It uses SAP/SDP, not NMOS. It has not been specifically tested as ST2110-30, even though ST2110-30 is closely related to AES67. It needed IEEE 802.3x flow control enabled to prevent an ugly 8% packet loss during high-rate multicast streams. Anyone pretending multicast audio on commodity Ethernet is “just packets” deserves to debug dropouts in front of a drummer.
But the interoperability claims are enough to make this more than a lab toy. The implementation was tested against aes67-linux-daemon on Raspberry Pi, Merging Technologies SIENNA, and a standalone AES67 hardware speaker. That puts it in contact with actual ecosystem edges, not just itself in a mirror.
The historical context is why this lands. RAVENNA’s own AES67 explainer frames AES67 as an interoperability layer, not a complete audio product: a set of guidelines so different IP audio systems can talk, with RAVENNA positioned as a mature implementation path. That distinction matters. AES67 was ratified in 2013, and it was supposed to make audio networking less tribal. In practice, the professional audio world still got a pile of branded islands, certification rituals, switch folklore, and “open” standards that most musicians encountered as expensive boxes with locked-down control panels.
An ESP32-P4 endpoint does not erase that. It does something more useful: it lowers the cost of weirdness.
If AES67 can run credibly on a RISC-V microcontroller with a sane component registry install, the imagination changes. A DIY stagebox is no longer “build a USB audio interface and pray.” A hardware sequencer can become a network clock participant. A modular synth case can speak multicast audio without a laptop. Gallery installations can scatter synchronized speakers across Ethernet without every node being a small Linux computer with a fragile filesystem. Live coding rigs can treat audio endpoints as addressable network objects instead of a pile of USB devices fighting over ground noise and driver moods.
This is also the part where the open-source audio crowd should get less romantic and more disciplined. Networked audio is not a vibe. It is clocks, buffers, packet timing, switch behavior, discovery, and failure modes. The cool thing about this ESP32-P4 work is not that it makes AES67 “accessible” in the marketing sense. The cool thing is that it exposes the actual constraints in a form small enough to understand. You can read the modules. You can see where lwIP is too slow. You can see why PTP hardware timestamping is mandatory. You can see why flow control made the difference between music and Rice Krispies.
That is how a serious creative toolchain starts: not with a glossy app store for musicians, but with a hard little component that makes the invisible timing layer programmable.
There is a lesson here for music technology generally. The next frontier is not another skeuomorphic compressor with a fake tube glow. It is infrastructure becoming small, inspectable, and composable enough that artists can route time, control, and audio as first-class material. MIDI did that for notes. OSC did it for control in experimental rooms. AES67 on microcontrollers hints at the same move for uncompressed network audio.
The protocol did not suddenly become simple. The ecosystem did not suddenly become pure. Dante will not vanish because a dev board learned PTP. But a door opened. Networked audio stopped looking exclusively like a broadcast facility problem and started looking like firmware.
That is where the good machines come from.