Receive deadlines
Maps RTP presentation times to controlled ALSA delivery as stream count rises.
AES67 RX/TX TECHNOLOGY
Audio in and out.
One media engine.
Bama Box brings the complete AES67 media path into Linux userspace on the product processor. Receive and transmit are implemented and measured, with timing control and multichannel scale designed for OEM integration.
USERSPACE AES67 RX/TX MEDIA ENGINE PTP MAPPED
STANDARD LINUX INTERFACESNO CUSTOM KERNEL MODULEHW TIMESTAMPS VIA API
256 RX + 256 TXmeasured simultaneously
64 receive channels · 1 ms8 streams × 8 channels
256 receive channels · 3 ms32 streams × 8 channels
WHAT THE ANIMATION SHOWSTwo directions.
Two directions.
One media engine.
Receive and transmit share one portable userspace architecture. Each direction applies the timing control it needs while presenting a clear ALSA boundary to the OEM product.
Jitter + drift control
Absorbs network variation and tracks the physical device clock against PTP.
Transmit scheduling
Moves product audio onto the network with controlled packet timing.
PTP time mapping
Consumes platform timestamps through an OEM-facing software API.
ALSA integration
Connects product audio to receive and transmit through standard Linux interfaces.
Userspace portability
Runs without a custom kernel module and is not tied to one CPU core, SoC family or board.
AES67 + PRODUCT AUDIO
One media engine. Integrated or modular.
Bama Box places deterministic AES67 receive and transmit processing in Linux userspace. It can run within a product that already has suitable Linux compute or inside a dedicated AoIP module for equipment that needs a self-contained network-audio subsystem.
hardware timestamps via API
transmit scheduling
channel and lane mapping
qualified on target hardware
The unified media engine sustained 256 receive and 256 transmit channels simultaneously on the same quad-core Arm reference platform.
Linux SoCs may expose multiple SAI/TDM interfaces and PTP-capable Ethernet, but the available routing and board connections vary by device and design.
The same media engine supports both deployment models while the OEM or module vendor supplies the surrounding control, timing and physical-audio architecture.
Platform fit: NXP i.MX 8M Plus, i.MX 93 and i.MX 95 are examples of Linux application-processor families with Ethernet and native audio interfaces. The OEM qualification maps Bama Box to the selected NIC/PTP implementation, BSP and SAI/TDM fabric.
CONTROL-PLANE INDEPENDENTKeep your control plane.
Keep your control plane.
Change the media engine.
The Bama Box media engine accepts normalized stream configuration through a defined adapter. OEM discovery, routing and product-control software can stay in place while Bama Box handles the time-critical RX/TX media path.
DEFINED BOUNDARYStream adapterconfiguration · status · lifecycle
PATENT-PENDING USERSPACEBama Box RX/TX enginereceive timing · transmit scheduling · ALSA
Working receive reference: the unchanged linux-aes67-daemon REST/SDP control plane can configure the Bama Box receive path as an alternative media backend. The defined adapter model lets an OEM retain its product control layer while integrating the complete RX/TX engine.
USER SPACE · UNCHANGED REST + SDP CONTROL PLANElinux-aes67-daemonadd · status · rename · remove
USER SPACEControl-plane bridgeDaemon-managed configuration
KERNEL BOUNDARY
KERNEL SPACERAVENNA media moduleCustom kernel media backend
USER SPACEBama Box receiverPTP · jitter · deadlines · ALSA
KERNEL BOUNDARY
KERNEL SPACEStandard Linux interfacesNetworking + ALSA · no custom media module
Same userspace control plane, different media placement: the tested stock path runs its media backend as a custom kernel module; Bama Box runs the receiver in userspace and uses standard Linux networking and ALSA interfaces.
PRODUCT AUDIO BOUNDARYALSA ↔ Bama Box ↔ AES67Receive and transmit use the product-defined channel and device layout.
Connect one or many product-defined ALSA devices to the bidirectional media engine. Physical interface capacity and clock integration are established on the OEM target platform.
CLOCK CONTROL IN PRACTICEDrift is measured.
Drift is measured.
Correction is declared.
In the measured PCM5122 run, the device consumed roughly one extra 48 kHz frame—20.83 µs—about every ten seconds. The controller tracked the difference and made six declared single-frame repeats during 60 seconds.
The observation covers frame-level clock control; analog end-to-end latency sits outside this measurement boundary.
CONTROLLERTRACKS OFFSETframe-level correction
The audio-device hand advances slightly faster than the PTP reference. The visual difference is exaggerated; the measured drift was approximately one 48 kHz frame per ten seconds.
0 s6 declared one-frame repeats60 s
OEM-SUPPLIED BOUNDARY
Your hardware. A defined software adapter.
The remaining OEM integration is the platform boundary: timestamps, clocks, NIC capabilities and audio interfaces are exposed through a defined software API. The RX/TX media engine is portable across Linux-capable processors; physical channel capacity and performance are established on the OEM target.
Arm Cortex Linux SoCsNXP i.MX familiesx86 systemsOther Linux platforms
BENCHMARK IT ON YOUR SOC
Benchmark your target platform Bring your timing and audio interfaces.
We can define the adapter boundary and run a confidential AES67 media-path benchmark on the target hardware.