The Media Kit: Real-Time Audio and Video in Haiku
Haiku's Media Kit models audio and video processing as a graph of connected nodes passing buffers to each other in real time — the same conceptual model professional media software still uses today.
Handling audio and video isn’t just “read some bytes and play them” — real-time media has hard timing requirements (a dropped audio buffer is audible instantly as a click or gap), needs to support many different sources and destinations, and often needs several processing steps chained together. Haiku’s Media Kit models all of this as a graph of connected nodes.
Nodes and connections
A BMediaNode represents one participant in a media pipeline — an audio input device, a format converter, an equalizer effect, an output device. Nodes are connected together explicitly, with buffers of media data flowing from node to node along those connections:
[Microphone input node] → [Format converter node] → [Effect node] → [Speaker output node]Each node declares what kinds of input and output connections it supports, and the Media Server — a system service running continuously in the background — is responsible for routing buffers between connected nodes and keeping the whole graph synchronized in real time.
Why a central Media Server, rather than direct point-to-point connections
Routing all media data through a central server process, rather than having applications talk directly to hardware or to each other, is what allows multiple applications to participate in the same media graph simultaneously — one application capturing audio while another simultaneously applies an effect and a third handles output, without those applications needing any direct knowledge of each other. The Media Server also owns the system’s global notion of which physical devices are currently available, so applications discover and connect to real hardware through it rather than each needing separate, potentially conflicting device-level access.
Timing: the hardest part of any real-time media system
Every buffer that flows through the graph carries timing information, and nodes are expected to process and deliver buffers according to that timing — a video node has meaningfully less slack than most other software, since a late frame is a dropped frame with no good way to “catch up” invisibly. The Media Kit’s node-based design exists largely to make this timing discipline structural: because every node’s job is precisely defined (accept a buffer, process it, emit a buffer, on schedule), the Media Server can reason about and enforce timing constraints across an entire pipeline rather than each individual application having to implement its own real-time scheduling logic from scratch.
Why this fits Haiku’s broader design so naturally
A node-graph model where independent units process and pass along buffers concurrently is a direct, domain-specific application of the same pervasively multithreaded, message-passing philosophy that runs through the rest of Haiku’s design — each active node reasonably corresponds to its own thread, communicating through well-defined buffer handoffs rather than shared mutable state. Media handling wasn’t retrofitted onto a system designed around a different concurrency model; it’s built from the same underlying assumptions the kernel and the Looper/Handler pattern already establish.
A legacy from BeOS’s original positioning
BeOS was originally positioned specifically as a platform for multimedia content creation, and the Media Kit’s sophistication reflects that original priority directly — real-time, low-latency, multi-application media handling wasn’t a secondary feature bolted on later, it was close to the platform’s founding reason to exist. Haiku inheriting this design wholesale means a modern, open-source, general-purpose OS still carries a genuinely capable real-time media architecture as a core part of its native API, rather than treating audio/video handling as an afterthought layered on top of a system designed for other priorities.