The broadcast industry is undergoing a fundamental shift from hardware-centric systems to software-defined infrastructure, a move championed by initiatives like the EBU Dynamic Media Facility (DMF). At the heart of this transition lies the Media eXchange Layer (MXL), a high-performance data plane designed to solve the interoperability challenges of virtualized production. While MXL handles video through discrete grains, its approach to audio—via Continuous Flows—represents a sophisticated evolution in how compute resources exchange data using shared memory.
The Move from Sending to Sharing
Traditional IP broadcast workflows rely on a “sender/receiver” model involving packetization and network overhead. MXL replaces this with a shared memory model. In this architecture, media functions (such as audio processors or mixers) do not “send” audio; rather, they write data to memory-mapped files located in a tmpfs (RAM disk) backed volume known as an MXL Domain.
This allows for a “zero-overhead” exchange where readers and writers access the same physical memory, eliminating the CPU cycles usually wasted on copying data or managing network stacks.
Continuous Flows: Audio as a Stream
Unlike video, which is handled as “Discrete Grains” (individual frames), MXL treats audio as Continuous Flows. This distinction is critical for low-latency processing.
The standard format for these flows is audio/float32, utilizing 32-bit IEEE 754 floating-point values with a full-scale range of [-1.0, +1.0]. This mirrors the high-fidelity representation found in professional DAWs and RIFF/WAV files.
The Architecture of the Ring Buffer
To manage this continuous stream, MXL allocates de-interleaved channel ring buffers. The audio samples are stored in a specific shared memory blob named channels within the flow’s directory.
The layout of this memory is sequential and predictable:
• The buffer for Channel 0 takes up the first block (defined by bufferLength * sampleWordSize).
• This is immediately followed by the buffer for Channel 1, and so on for all N channels.
This “de-interleaved” (planar) structure allows processing functions to access specific channels efficiently without parsing interleaved data packets.
Frictionless Access: Slices and Strides
Because the audio data lives in a circular ring buffer, accessing a specific window of time presents a unique challenge: the data might wrap around the end of the buffer to the beginning.
MXL solves this with the mxlWrappedMultiBufferSlice structure. When a reader requests samples, the API returns two memory fragments (slices). If the requested audio is contiguous, the second fragment size is zero; if it wraps around, the API provides pointers to both the end and the beginning of the buffer seamlessly.
To read across multiple channels, the system uses a stride, which defines the byte distance required to jump from a sample in one channel to the same sample in the next.
Concurrency without Contention
A major advantage of this architecture is its thread safety in containerized environments. MXL manages synchronization using futexes rather than POSIX mutexes. This allows readers to map the flow resources in read-only mode (PROT_READ), ensuring that a crashing reader cannot corrupt the shared memory.
To prevent race conditions, the architecture enforces a strict rule: readers may only observe a window of samples smaller than half the buffer length. The other half is reserved as “write in progress,” ensuring that producers and consumers never collide while accessing the high-speed ring buffer.
By treating audio as a continuous, memory-mapped stream, MXL provides the technical foundation for the next generation of media compute—enabling flexible, “faster-than-live” workflows without sacrificing the fidelity or reliability required by professional broadcast.
