Architecture Fundamentals

Flow organization through the separation of control/rendering

I/O is built on the concept of an audio context or AudioGraph.

A node graph defines the path a sound follows from its source —which may be, for example, an audio file— to the output device, describing each intermediate signal transformation.

As the signal flows through each node, its properties may be modified.

In this model, nodes are represented as blocks and connections as directional links, with each node supporting multiple inputs and outputs. By default, if a node receives multiple connections, I/O sums all incoming signals combining them into a consolidated path.

Threads

Low-latency audio systems are commonly implemented using callback functions, where the operating system invokes the program whenever audio must be generated to keep playback continuous, providing a predictable mechanism for real-time signal production.

Execution occurs on a high-priority thread; crossing boundaries or introducing buffering inevitably adds latency and reduces fault tolerance.

I/O is implemented using a control thread and a render thread.

The control thread is where the AudioGraph is instantiated and where developers manipulate the graph, invoking operations. This thread uses an event loop, while the render thread runs a specialized loop that computes the signal in response to actions performed on that control thread.

Communication between threads occurs through messages sent from the control plane, and in the opposite direction through regular event-loop tasks.

Automation

One of I/O’s main strengths is that it incorporates a low-latency timing model. Timing enables scheduling events to occur at specific future moments, which is particularly useful in scenes and spatial applications that depend on precise temporal coordination.

The context provides its own temporal model and reference frame.

The design based on two threads allows audio processing to occur deterministically without blocking the UI or compromising system stability. Graph operations are validated on the control thread and executed asynchronously on the render thread.

Operations

In I/O, operations on an AudioNode are divided into two phases:

• A synchronous phase, executed on the control thread for parameter changes.

• An asynchronous phase, executed on the render thread through an enqueued message.

This guarantees safety when modifying parameters or states without blocking processing. If operation A is invoked before operation B, both their synchronous and asynchronous phases must execute in the same order, preventing any reordering.

Nodes

Nodes can be classified into three broad categories.

Source nodes include components such as audio players, buffers, live inputs, generators and oscillators, while Processing nodes include filters, equalization, reverberation, delays, spatializers among other FX. Finally, the Analysis nodes encompass real-time audio analyzers.

Although the final destination node is usually a playback system such as speakers, I/O also allows audio to be processed without being played back —for example, visualization or offline processing, where the audio stream is stored in a buffer for later use.

In interactive environments, multiple sources combine to form the final mix. These may include background music, effects, UI feedback, etc. Once established, the graph can be modified dynamically adapting its structure as the scene evolves.

I/O offers independent control over each channel, as well as over the entire set.

When an AudioNode receives multiple inputs, it adjusts channels through upmixing or downmixing to maintain signal compatibility. In nodes with tail-time, channel changes are applied only when the previous signal no longer contributes to the output.