3SB Audio

2026-06-17

Stack Status: Switch and NIC Qualification, and Architecture

The 3SB AVB/Milan stack has reached a point worth reporting on. Over the last several months the bulk of the work has not been new features but careful refinement: chasing down every source of media-clock disturbance, dropped audio frame, and listener unlock until the audio path runs cleanly and stays that way. This post summarises where the stack stands, the hardware we have qualified it against, how the pieces fit together, and what is coming next.

Performance refinement

A Milan audio path is only as good as its weakest timing margin. Much of the recent effort has gone into widening those margins and removing the conditions that erode them:

  • Media-clock stability. The media clock is the heartbeat of the system, and listeners are unforgiving of sudden rate changes. We traced and eliminated a class of clock excursions that could briefly perturb the media clock and unsettle a connected speaker, so the clock now tracks smoothly and the listeners stay locked.
  • Transmit timing. Audio frames are launched into the network against hardware launch-time and traffic-shaping engines on the network interface. We tuned these margins so frames land inside their windows reliably, under realistic system load, without the late or early arrivals that show up as stream interruptions.
  • Both connection styles. This hardening was carried out and validated for both a direct point-to-point link between the controller and a speaker, and a connection made through an AVB switch — where the switch relays the network clock and the timing behaviour is subtly different. Each path has been soaked over extended runs with no listener faults.

The result is a transport that comes up cleanly from a cold boot, recovers predictably, and runs indefinitely without operator intervention.

Qualified AVB switches

Most multi-device Milan systems are connected through an AVB-capable switch, which distributes the network clock and reserves bandwidth for the audio streams. We have now qualified the stack end-to-end with two switches:

  • PreSonus AVB SW5E. A compact five-port AVB switch, well suited to a small system of a controller, a pair of speakers, and an input device.
  • Netgear M4250 (AV line). A managed AV switch with an AVB/Milan port profile, suitable for larger or mixed installations.

The two behave differently as clock sources, and the stack adapts to either automatically. The Netgear M4250 can serve as the network clock grandmaster itself, originating timing and distributing it to the controller and speakers. The PreSonus SW5E acts as an AVB bridge: rather than originating the clock it relays gPTP timing through, so in that topology the grandmaster is the controller or another endpoint and the switch passes the reference along. Either way, the stack discovers whichever device is grandmaster and aligns its on-wire timing to it.

Qualified network interfaces

The controller needs an Intel Ethernet interface with the time-sensitive networking features Milan depends on — precise hardware timestamping, launch-time transmission, and bandwidth shaping. We have qualified the following parts:

  • Intel i210 — qualified on the i210-AT. The i210-IT (industrial temperature grade) is the same silicon and is expected to work equally well.
  • Intel i226 — qualified on the i226-LM. The i226-IT should also be fine. The consumer i226-V variant is not supported and should be avoided for controller builds.

Picking a qualified interface is the single most important hardware decision when assembling a controller; the rest of the platform is comparatively forgiving.

Direct and switched deployment

The stack supports two ways of reaching the speakers. A direct point-to-point connection from the controller to a single Milan device works today and has been hardened alongside the switched path. We are now extending the direct path to drive multiple Ethernet interfaces from one controller, so that a small system — for example a stereo pair plus an input device — can be wired directly, without a switch at all.

That multi-interface direct path is still in development. For now, an AVB switch is the preferred deployment method: it is the most thoroughly tested topology, it scales cleanly, and it keeps the clocking and bandwidth-reservation behaviour consistent regardless of how many devices are attached.

How the stack holds together

Conceptually, the controller is a pipeline. Audio enters from a source, passes through digital signal processing, and is then carried over the network to the speakers as Milan streams — all running against a single shared media clock.

3SB stack signal and media-clock flow Audio flows from the source player, through ingress, the DSP engine (which performs room-correction filtering, channel routing and sample-rate conversion), a shared media-clock ring, the Milan transport (audio streams plus a clock-reference stream), an AVB switch or a direct connection, and finally to the 3SB speakers. A network-wide gPTP media clock underpins every stage. Source player — Roon, networked players, USB-DAC bridge Ingress — adapts source audio into the internal path DSP engine — CamillaDSP or BruteFIR room-correction FIR · channel routing · sample-rate conversion Shared media-clock ring — one clock for DSP and transport Milan transport — audio streams + clock-reference (CRF) stream AVB switch (preferred) — or direct multi-interface (in development) 3SB Milan speakers — DAC and amplification in each cabinet gPTP (802.1AS) media clock underpins every stage grandmaster on the AVB switch or an endpoint
Conceptual signal and media-clock flow through the 3SB stack.

Working through the stages:

  • Ingress. Source audio — for example a Roon stream — is adapted from the user-facing playback path into the controller's internal transport.
  • DSP engine. CamillaDSP or BruteFIR applies room-correction filtering and routes channels to the correct speakers. Importantly, the DSP layer is also where sample-rate conversion happens: a source can arrive at one rate while the stack runs its media clock at another, and CamillaDSP resamples the source to the stack rate so the rest of the pipeline sees a single, consistent rate. This decouples whatever the source is playing from the fixed rate the network transport and speakers expect.
  • Shared media-clock ring. A kernel module presents a common audio timeline that both the DSP output side and the network transport side attach to. Sharing one clock here is what keeps DSP and transport from drifting against each other.
  • Milan transport. The rendered audio is packetised into Milan audio streams, accompanied by a clock-reference (CRF) stream that carries the media clock to the listeners.
  • Network and speakers. The streams travel through the AVB switch (or a direct link) to the 3SB speakers, each of which integrates its own DAC and amplification.
  • gPTP media clock. Underneath everything, the 802.1AS network clock keeps the controller and every speaker on a common timebase. A grandmaster — the switch or an endpoint — sets the reference, and the stack aligns its on-wire timing to it.

Operating the stack

Around the audio pipeline sit the tools an operator actually interacts with:

  • 3sb-config compiles a small, human-authored site description — the speakers, their layout, and the streams — into the runtime configuration the stack needs, and applies it. It is how an installation is described once and brought up repeatably.
  • 3sb-monitor watches the audio path end to end — clocking, streams, and per-speaker status — and surfaces it two ways: a terminal (CLI) view for hands-on work and headless setups, and a web interface for at-a-glance health. If a stream is not flowing or a clock is not locked, this is where it shows up immediately.

Together they keep the system describable, repeatable, and observable, which is as important to a reliable installation as the transport itself.

What's next

Two threads are active. The first is finishing the multi-interface direct path described above, so switchless small systems become a first-class deployment option. The second is adding OCA (Open Control Architecture / AES70) support for control of the DSP functions, so that parameters such as levels and room-correction settings can be controlled over the network through a standard, interoperable protocol rather than a bespoke interface. Rather than implement the protocol from the ground up, we intend to build on the excellent open-source AES70/OCA work from PADL Software (SwiftOCA).

Interested in testing?

The stack is under active development and we are looking for testers. It is likely to suit you if you are working on something like:

  • Active loudspeaker design. Centralise the DSP and crossover in the controller and stream rendered audio to networked amplifier/DAC modules, so each cabinet stays fully active without needing its own DSP on board.
  • Multi-way and multi-channel systems. Installations of up to 32 channels — for example multi-amplified speakers, subwoofers, and bass extenders, or a larger multi-speaker layout driven from a single controller.
  • Whole-room and multi-speaker installations. Several Milan endpoints fed from one controller over an AVB switch, with DSP and routing managed centrally rather than per device.
  • Room correction and FIR experimentation. Heavy, centralised FIR processing through BruteFIR or CamillaDSP, applied consistently across every output.
  • Milan / AVB integration work. A Linux Milan talker to test interoperability against Milan listener devices and AVB infrastructure.

If any of that sounds like your project, please register for an account on the portal. Approved accounts receive credentials for the development package repository and updates as the stack progresses.