Data Routing, Multiplexing & Selection Architecture: Copier, Multiplexer & Selector#

In Sound Open Firmware (SOF), audio processing pipelines are decoupled from raw hardware transport and stream topology management. The subsystem responsible for moving audio data across execution boundaries, translating stream formats, routing multiple audio channels, and synchronizing hardware streams consists of three foundational components:

  • Copier: The universal boundary data mover and hardware endpoint abstraction module. In IPC4 architectures, the Copier interfaces directly with DMA engines (Host DMA, Digital Audio Interfaces, and Inter-Core IPC Gateways), provides 1-to-N multi-pin stream fan-out, executes dynamic per-sink PCM format conversions, tracks Linear Link Position (LLP) telemetry, and latches DSP wall-clock hardware timestamps.

  • Multiplexer & Demultiplexer (Mux/Demux): The multi-stream channel routing crossbar. In IPC3, the Mux/Demux dynamically cross-connects audio channels between \(N\) inputs and \(M\) outputs via bitmask routing matrices. In IPC4, the Multiplexer serves as the standardized multi-pin stream aggregator for Echo Cancellation (AEC), fusing primary microphone capture audio with reference playback streams into a synchronized multi-channel stream.

  • Selector: The intra-stream channel extraction, permutation, and linear downmixing engine. Operating within a single stream, the Selector extracts designated channel subsets (e.g. isolating active microphones from a high-density microphone array), swaps channel assignments, and executes arbitrary \(8 \times 8\) matrix mixing in \(Q10\) fixed-point arithmetic.

Together, these three components establish the complete routing, fan-out, aggregation, and isolation infrastructure required by modern multi-stream audio architectures.

—

Executive Architecture Overview: The SOF Data Routing & Endpoint Ecosystem#

Audio data routing within a modern digital signal processor must reconcile two divergent architectural requirements:

  1. Hardware Transport Decoupling: Hardware peripherals (PCIe Host DMA, High Definition Audio links, Serial Synchronous Ports, SoundWire Audio Link Hubs, and PDM digital microphones) operate with rigid FIFO layouts, burst alignments, and hardware frame rates. Internal DSP algorithms, conversely, require uniform circular buffers, predictable frame block sizes, and arbitrary bit depths.

  2. Dynamic Stream Topologies: Operating systems and audio middleware demand complex routing topologies—including simultaneous media playback, voice assistant capture, acoustic echo cancellation loopback taps, multi-mic spatial beamforming, and offload processing—all sharing concurrent access to shared audio streams without mutual interference.

SOF resolves these demands through a strict separation of concerns among the Copier, Multiplexer, and Selector components:

Table 8 SOF Routing Component Capability Matrix#

Capability / Feature

Copier Subsystem

Multiplexer / Demux

Selector Component

Primary Purpose

Hardware endpoint bridging, stream splitting & format conversion.

Multi-stream channel crossbar & IPC4 AEC stream aggregation.

Intra-stream channel selection, permutation, and matrix downmixing.

Pin Topology

1 Input Pin, up to 4 Output Pins (Fan-out).

IPC3: N-in / 1-out (Mux) or 1-in / N-out (Demux). IPC4: 2-in (Mic/Ref), 1-out.

1 Input Pin, 1 Output Pin.

Hardware Gateways

Direct interface to Host, DAI, & IPC gateways on Pin 0.

None (Internal DSP stream routing only).

None (Internal DSP stream processing only).

Format Adaptation

Dynamic per-sink format conversion on all sinks.

Matches input/output stream channel counts & formats.

Operates on native audio formats with matrix math.

Mathematical Model

Bit-depth conversion, frame shift attenuation (\(x \gg k\)).

Bitmask matrix cross-wiring (\(\text{mask}[\text{ch}]\)).

\(8 \times 8\) \(Q10\) fixed-point coefficient matrix.

Timing & Telemetry

Linear Link Position (LLP) & DSP Wall-Clock Timestamps.

Zero-latency sample pass-through with reference sync.

Frame-synchronized sample selection & mixing.

—

Copier Subsystem Deep Dive: Hardware Endpoint Abstraction#

The Copier (UUID 9ba00c83-ca12-4a83-943c-1fa2e82f9dda) is the mandatory endpoint and pipeline boundary module in SOF IPC4 architectures. Every pipeline that exchanges audio with the host operating system or external audio codecs begins or terminates with a Copier instance.

Binding Configurations#

A Copier instance can be instantiated and bound within a pipeline in four distinct topological configurations:

  1. Input Gateway Ingestion (Case 1): Connects an input hardware gateway to downstream DSP processing modules:

    \[\text{InputGateway} \longrightarrow \text{Copier} \longrightarrow \text{DestinationModule}\]

    Used for host playback pipelines (where the gateway is a Host DMA stream) and audio capture pipelines (where the gateway is a DAI interface receiving from microphones or line-in).

  2. Output Gateway Transmission (Case 2): Connects upstream DSP processing modules to an output hardware gateway:

    \[\text{SourceModule} \longrightarrow \text{Copier} \longrightarrow \text{OutputGateway}\]

    Used for speaker playback pipelines (delivering processed audio to DAI hardware) and host recording pipelines (delivering captured audio to Host DMA ring buffers).

  3. Inter-Module Format Bridging (Case 3): Connects two internal DSP modules without a hardware gateway:

    \[\text{SourceModule} \longrightarrow \text{Copier} \longrightarrow \text{DestinationModule}\]

    Used when splitting pipelines across distinct scheduling domains, core boundaries, or when executing complex format adaptations between incompatible processing modules.

  4. Gateway Transmission with Local Tap (Case 4): Connects upstream DSP modules simultaneously to an output gateway and one or more internal destination modules:

    \[\begin{split}\text{SourceModule} \longrightarrow \text{Copier} \begin{cases} \longrightarrow \text{OutputGateway} \\ \longrightarrow \text{DestinationModule} \end{cases}\end{split}\]

    Used for hardware loopback taps, where speaker playback audio is transmitted to the physical amplifier while simultaneously being tapped and fed into an Echo Cancellation reference pipeline.

Important

The Gateway Pin 0 Invariant: In all Copier configurations interfacing with hardware, the gateway is strictly connected to Pin 0 (Input Pin 0 for input gateways, Output Pin 0 for output gateways). Auxiliary destination modules and loopback taps are bound exclusively to Output Pins 1, 2, or 3.

Architecture of SOF data movement showing Host Copier, DAI Copier, and Gateway Copier binding cases with circular buffers and DMA engines.

Figure 133 Figure 174: SOF Data Movement and Gateway Interconnect Topology (Host Copier, DAI Copier, and Gateway Copier)#

Host Copier Engine#

The Host Copier connects the DSP memory space to the host operating system’s cyclic DMA buffers. In playback mode, it pulls audio data from host memory into DSP local memory; in capture mode, it pushes processed DSP frames to host memory.

  • Circular Buffer Pointer Tracking: The Host Copier continuously tracks host read/write pointers. It calculates available space and data counts, handles circular buffer wrap-around, and notifies the host driver when period elapsed events occur.

  • Frame Position Index (FPI) Synchronization Groups: To prevent phase drift across multi-stream presentations (such as multichannel audio where front, rear, and center/subwoofer channels are split across multiple ALSA substreams), SOF provides FPI update groups (CONFIG_HOST_DMA_STREAM_SYNCHRONIZATION). Multiple Host Copiers can be assigned to a common fpi_sync_group with a shared update period in microseconds. All copiers within the group latch and update their host FIFO position indices synchronously, ensuring perfect phase alignment.

DAI Copier Engine#

The DAI Copier bridges DSP audio buffers to external digital audio serial buses:

  • High Definition Audio (HDA): Direct connection to Intel HDA link DMA streams.

  • Serial Synchronous Port (SSP / I2S): Interfaces with standard I2S, left-justified, right-justified, or multichannel TDM serial codecs.

  • Digital Microphone (DMIC): Interfaces with hardware PDM decimation filters, capturing up to 8 digital microphone channels.

  • SoundWire / Audio Link Hub (ALH): Implements multi-gateway aggregation (is_multi_gateway(node_id)). When high-channel-count audio (e.g. 4-channel surround or multi-speaker smart amps) is distributed across multiple SoundWire Data Port Interfaces (PDIs), the DAI Copier inspects the sof_alh_configuration_blob, instantiates multiple DAI sub-indices, and automatically multiplexes or demultiplexes the multichannel stream across physical SoundWire data lines using nibble-encoded channel bitmasks.

IPC Gateway Copier#

When audio must traverse pipeline boundaries across heterogeneous DSP cores (such as passing decoded media frames from Primary Core 0 to Secondary Core 1 for post-processing), the IPC Gateway Copier uses hardware Inter-Processor Communication (IPC) gateways or shared SRAM FIFO windows. It decouples the scheduling loops of the two pipelines without engaging host DMA channels or triggering host interrupts.

Copier Fast Mode#

Under normal scheduling, a Copier transfers exactly its configured Input Block Size (IBS) or Output Block Size (OBS) per scheduling period. When IPC4_COPIER_FAST_MODE is enabled in the copier feature mask, the Copier is permitted to burst-transfer multiples of the block size in a single execution tick. Fast Mode is activated during pipeline pre-filling and deep-sleep playback buffer draining, provided all downstream sinks are bound to data-processing queues rather than fixed real-time DAIs.

—

Multi-Pin Fan-Out & Dynamic Per-Sink Format Conversion#

In modern audio architectures, a single audio source must frequently be distributed to multiple consumers operating with distinct sample rates, bit depths, or channel layouts. The Copier natively provides a 1-to-N stream splitter with independent format conversion per output pin.

Stream Fan-Out Topologies#

The Copier supports up to 4 simultaneous output pins (\(\text{Pin}_0, \text{Pin}_1, \text{Pin}_2, \text{Pin}_3\)). Each output pin operates with its own circular buffer sink and independently configured audio format:

\[\begin{split}x_{\text{in}}[n] \in \mathcal{F}_{\text{in}} \xrightarrow{\text{Copier}} \begin{cases} y_0[n] \in \mathcal{F}_{\text{out}, 0} & (\text{Pin 0: Hardware Gateway or Primary Pipeline}) \\ y_1[n] \in \mathcal{F}_{\text{out}, 1} & (\text{Pin 1: Acoustic Echo Cancellation Reference Tap}) \\ y_2[n] \in \mathcal{F}_{\text{out}, 2} & (\text{Pin 2: Speech Recognition / Hotword Detector}) \\ y_3[n] \in \mathcal{F}_{\text{out}, 3} & (\text{Pin 3: Telemetry / Loopback Monitor}) \end{cases}\end{split}\]

Runtime Per-Sink Format Setup#

While Pin 0’s format is established during initial module instantiation, auxiliary output pins (Pins 1 through 3) can be dynamically configured at runtime via the IPC4 command IPC4_COPIER_MODULE_CFG_PARAM_SET_SINK_FORMAT. The host driver supplies a configuration structure specifying:

  • Target Sink Identifier (Pin Index).

  • Upstream Source Audio Format (validating that the input stream format matches expected characteristics).

  • Downstream Sink Audio Format (specifying target container bit depth, valid bit resolution, channel count, sample rate, and interleaving scheme).

Dedicated PCM Converter Execution#

When an output pin’s target format differs from the input stream, the Copier dynamically binds a specialized PCM converter routine (pcm_converter_func) for that specific pin. During every processing period, the Copier reads input audio frames once, pushes un-converted samples directly to sinks with matching formats, and passes the input frames through the dedicated converter routines for sinks requiring transformation:

  • Container Width Conversion: 16-bit packed (\(S16\_LE\)), 24-bit in 32-bit container (\(S24\_4LE\)), and 32-bit full scale (\(S32\_LE\)).

  • Bit Depth Formatting: Arithmetic sign extension, arithmetic left/right shifting, and bit truncation.

  • Channel Layout Adaptation: Selective channel stripping, channel duplication, or channel remapping according to the runtime channel mask.

Diagram of Copier 4-way stream splitting showing input pin and 4 output pins with independent PCM format conversion engines.

Figure 134 Figure 175: Copier 4-Way Stream Splitting & Dynamic Per-Sink Format Conversion Pipeline#

—

Integrated Copier Gain & Attenuation Architecture#

In addition to routing and format adaptation, the Copier provides integrated sample attenuation and gain management. This capability allows topologies to control audio levels and prevent clipping at boundary interfaces without the memory and scheduling overhead of dedicating an independent Volume processing widget.

Static Bit-Shift Attenuation#

For high-bit-depth audio streams, the Copier supports direct hardware-style attenuation via arithmetic bit shifting:

  • Configuration: Commanded via IPC4_COPIER_MODULE_CFG_ATTENUATION.

  • Application Scope: Permitted when the output pin is configured for 32-bit sample containers and the source is bound to a hardware gateway.

  • Mathematical Operation: For an attenuation parameter \(A \in [1..31]\), every output sample is arithmetically right-shifted:

    \[y[n] = x[n] \gg A\]

    This provides rapid, zero-multiplication step attenuation in \(6 \text{ dB}\) increments (\(-6 \text{ dB}, -12 \text{ dB}, -18 \text{ dB}, \dots\)), ideal for safeguarding high-power digital amplifier stages during link bring-up.

Copier Gain Engine#

When configured with CONFIG_COPIER_GAIN, the Copier incorporates a dedicated gain sub-engine:

  • Static Volume Gain: Applies linear channel-specific scaling factors.

  • Mute Control: Instantly forces sample values to digital zero without disrupting stream framing or tearing down DMA descriptors.

  • Smooth Transition Ramping: When changing volume levels or toggling mute, the Copier Gain engine applies smooth linear or exponential sample ramps across configurable millisecond durations. This completely suppresses audible pops, clicks, or zipper noise during stream transitions.

—

Multiplexer & Demultiplexer Architecture: Matrix Bitmask Crossbar#

The Multiplexer / Demultiplexer component (UUID 68:68:b2:c4:30:14:0e:47:a0:89:15:d1:c7:7f:85:1a) is the channel crossbar router of Sound Open Firmware. Unlike audio mixers (such as Mixin/Mixout), the Multiplexer performs pure channel routing and stream aggregation: it copies, redistributes, or splits individual audio channels without summing or arithmetic scaling.

Matrix Bitmask Routing Model#

In IPC3 topologies, routing between input and output streams is defined by an \(8 \times 8\) binary routing matrix encoded into an array of 8-bit masks:

\[\mathbf{M} \in \{0, 1\}^{8 \times 8}\]

  • Multiplexer Mode (\(N\) Inputs \(\to\) 1 Output): Each stream maintains an array mask[PLATFORM_MAX_CHANNELS], where each element corresponds to an input channel. The bit positions set within mask[ch] indicate the designated output channels to which that input channel must be copied:

    \[y[\text{out\_ch}] = x[\text{in\_ch}] \quad \Longleftrightarrow \quad \left( \mathbf{M}_{\text{in\_ch}} \;\&\; (1 \ll \text{out\_ch}) \right) \neq 0\]

  • Demultiplexer Mode (1 Input \(\to\) \(N\) Outputs): In demultiplexer mode, the mapping is inverted: each element of mask[ch] corresponds to an output channel, and the bit positions indicate which input channel provides the source sample.

Note

Zero Mixing Invariant: The Multiplexer/Demultiplexer component strictly forbids audio mixing. If a configuration specifies multiple input channels mapped to the same output channel bit, the component rejects the configuration during initialization with an error.

Pre-Computed Lookup Tables#

To achieve zero-overhead execution during real-time processing, the component compiles the binary bitmask matrix into a pre-computed lookup table (mux_look_up) during the pipeline prepare phase. The lookup table resolves source and destination memory pointers, buffer offsets, channel stride increments (src_inc, dest_inc), and element counts. During inner processing loops, the DSP executes direct assembly copy operations without evaluating conditional branches or computing bit shifts.

Diagram of Mux and Demux channel routing showing 8x8 binary bitmask matrices and zero-overhead lookup table dispatch.

Figure 136 Figure 177: Multiplexer (Mux) & Demultiplexer (Demux) Channel Routing Matrix & Bitmask Architecture#

—

IPC4 Echo Cancellation (AEC) Reference Stream Aggregator#

In SOF IPC4 topologies, the Multiplexer component assumes a critical, standardized role: the Acoustic Echo Cancellation (AEC) Reference Stream Aggregator.

Speech processing algorithms, beamformers, and voice recognition engines require two synchronized audio inputs:

  1. The acoustic capture stream picked up by physical microphones (containing the user’s speech plus echo from the device’s loudspeakers).

  2. The reference playback stream sent to the loudspeakers (the pure echo source).

To pass both streams into a single processing algorithm via standard single-input module adapters, the Multiplexer aggregates them into a composite multi-channel stream.

Deterministic Channel Allocation#

In IPC4, the Multiplexer defines a deterministic pin mapping:

  • Input Pin 0 (Primary Capture Stream): Contains \(M\) channels (\(\text{Ch}_0 \dots \text{Ch}_{M-1}\), where \(M \le 4\)) representing the physical microphone signals. These channels are mapped directly to output channels \(0 \dots M-1\):

    \[y[\text{ch}] = x_0[\text{ch}], \quad \forall \; \text{ch} \in [0, M-1]\]

  • Input Pin 1 (Reference Stream): Contains \(N\) channels (\(\text{Ch}_0 \dots \text{Ch}_{N-1}\), where \(N \le 2\)) representing the loudspeaker playback signals tapped from the output Copier. These channels are appended immediately following the capture channels:

    \[y[M + \text{ch}] = x_1[\text{ch}], \quad \forall \; \text{ch} \in [0, N-1]\]

Total output channel count is therefore exactly \(M + N\). For example, a 2-channel microphone array combined with a 2-channel speaker reference yields a 4-channel output stream where channels 0 and 1 represent microphones and channels 2 and 3 represent reference audio.

Fault-Tolerant Zero-Padding Mechanics#

In real-time operating systems, playback streams can start, stop, or pause independently of microphone capture. If the loudspeaker playback pipeline stops, Input Pin 1 ceases delivering data.

To prevent pipeline stalling or algorithmic crashes in downstream AEC algorithms, the IPC4 Multiplexer implements autonomous fault tolerance:

  • Primary Stream Invariant: If Input Pin 0 (microphone capture) is disconnected or starving, the Multiplexer produces no output. Capture pipelines only execute when microphone data is actively present.

  • Reference Stream Zero-Padding: If Input Pin 1 (echo reference) is disconnected, paused, or starving, the Multiplexer does not stall. Instead, it processes microphone frames normally and automatically pads the reference output slots (\(M \dots M+N-1\)) with digital zeros:

    \[y[M + \text{ch}] = 0, \quad \forall \; \text{ch} \in [0, N-1]\]

This zero-padding ensures that downstream AEC algorithms maintain continuous frame synchronization without experiencing pipeline underflow, allowing transparent adaptation when media playback starts and stops.

Architecture of IPC4 Echo Cancellation stream aggregation showing Pin 0 mic capture, Pin 1 speaker reference tap, and zero-padding fallback.

Figure 137 Figure 178: IPC4 Echo Cancellation (AEC) Reference Stream Aggregation via Multiplexer#

—

Selector Component: Dynamic Channel Extraction, Permutation & Matrix Swapping#

While the Multiplexer routes audio channels across multiple streams, the Selector component (UUID c1:92:fe:32:17:1e:c2:4f:97:58:c7:f3:54:2e:98:0a) operates inside a single stream to isolate, rearrange, or downmix channels.

Channel Extraction and Dropping#

High-density audio interfaces frequently deliver more channels than required by downstream processing. For example, a digital microphone controller may provide an 8-channel TDM capture stream, whereas a voice assistant module requires only 2 primary microphone signals.

The Selector extracts the designated channels and drops the remainder:

\[\begin{split}\mathbf{y}[n] = \begin{bmatrix} x_{\text{sel}[0]}[n] \\ x_{\text{sel}[1]}[n] \end{bmatrix}, \quad \text{where } \mathbf{x}[n] \in \mathbb{R}^8, \; \mathbf{y}[n] \in \mathbb{R}^2\end{split}\]

In IPC3 mode, this is controlled by the configuration parameters in_channels_count, out_channels_count, and sel_channel.

IPC4 Fixed-Point Matrix Mixing Model#

In IPC4 architectures, the Selector evolves into a general-purpose linear matrix mixer. Channel routing, permutation, and downmixing are defined by an \(8 \times 8\) matrix of 16-bit signed coefficients in \(Q10\) fixed-point format (struct ipc4_selector_coeffs_config):

\[y_i[n] = \sum_{j=0}^{M-1} c_{i,j} \cdot x_j[n], \quad i \in [0, N-1]\]

where \(M\) is the input channel count, \(N\) is the output channel count, and \(c_{i,j}\) are the \(Q10\) mixing coefficients. In \(Q10\) arithmetic:

  • Unity gain (\(1.0\)) is represented by \(1024\) (SEL_COEF_ONE_Q10).

  • Complete attenuation (\(0.0\)) is represented by \(0\).

  • Half gain (\(-6.02 \text{ dB}\)) is represented by \(512\).

This matrix formulation enables diverse audio transformations:

  • Channel Permutation & Swapping: Setting off-diagonal coefficients to 1024 swaps channels (e.g. reversing Left and Right channels):

    \[\begin{split}\mathbf{C}_{\text{swap}} = \begin{bmatrix} 0 & 1024 \\ 1024 & 0 \end{bmatrix}\end{split}\]

  • Stereo-to-Mono Downmixing: Summing Left and Right channels with equal weighting (\(-6 \text{ dB}\) per channel) prevents arithmetic overflow:

    \[\mathbf{C}_{\text{downmix}} = \begin{bmatrix} 512 & 512 \end{bmatrix}\]

  • 5.1 Surround Downmixing: Converting 6-channel surround sound to 2-channel stereo with standard psychoacoustic ITU coefficients:

    \[\begin{split}\begin{aligned} L_{\text{out}} &= L + 0.707 C + 0.707 L_s \\ R_{\text{out}} &= R + 0.707 C + 0.707 R_s \end{aligned}\end{split}\]

Multi-Profile Configuration Caching#

A single Selector widget can store up to 8 distinct configuration profiles in memory (SEL_MAX_NUM_CONFIGS = 8). When stream parameters change dynamically (such as switching from stereo to quad-channel microphone capture), the Selector matches the active stream’s channel count and channel configuration against its cached profiles, applying the corresponding mixing coefficients instantly without issuing new IPC round-trips to the host driver.

Diagram of Selector component demonstrating 8x8 Q10 matrix mixing, channel extraction, channel swapping, and downmixing.

Figure 138 Figure 179: Selector Component: Dynamic Channel Extraction, Permutation & Matrix Swapping#

—

ALSA Topology 2 Integration & Widget Declarations#

In ALSA Topology 2 (topology2), the Copier, Multiplexer, and Selector are instantiated as declarative widget objects.

Copier Widget Declarations#

Copiers are defined using dedicated configuration templates in tools/topology/topology2/include/components/:

  • dai-copier.conf: Declares hardware interface copiers (HDA, SSP, DMIC, ALH) bound to physical DAIs. Attributes include copier_type, direction, node_type, and cpc (cycles per chunk).

  • host-copier.conf: Declares host PCM endpoint copiers interfacing with host DMA streams.

  • module-copier.conf: Declares inter-pipeline or inter-core boundary copiers.

All Copier widgets share the standardized UUID:

UUID: 83:0c:a0:9b:12:ca:83:4a:94:3c:1f:a2:e8:2f:9d:da

Multiplexer / Demultiplexer Widget Declarations#

Multiplexers and Demultiplexers are declared using muxdemux.conf with widget type effect:

Class.Widget."muxdemux" {
    UUID: "68:68:b2:c4:30:14:0e:47:a0:89:15:d1:c7:7f:85:1a"
    type: "effect"
    num_input_pins: 2
    num_output_pins: 1
}

The widget includes an ALSA byte control used to upload runtime routing matrices or AEC reference mappings.

Selector Widget Declarations#

The Selector is declared using micsel.conf with widget type effect:

Class.Widget."micsel" {
    UUID: "c1:92:fe:32:17:1e:c2:4f:97:58:c7:f3:54:2e:98:0a"
    type: "effect"
    num_input_pins: 1
    num_output_pins: 1
}

Its configuration blob carries the \(8 \times 8\) \(Q10\) coefficient tables and channel selection masks.

—

End-to-End System Audio Graph: Component Synergy#

In production systems, Copier, Multiplexer, and Selector do not operate in isolation; they interact seamlessly across concurrent playback, capture, and voice assistant pipelines.

The following architectural graph illustrates how these components interlock in a complete PC audio topology featuring simultaneous media playback, acoustic echo cancellation, and beamformed voice capture:

Complete end-to-end audio graph showing Host Copier, Volume, DRC, DAI Copier, Selector, AEC Multiplexer, and Voice Pipeline.

Figure 139 Figure 180: End-to-End System Audio Graph: Media Playback, Voice Capture, AEC Muxing, and Loopback Monitoring#

Workflow Walkthrough#

  1. Host Ingestion: The Host Copier pulls stereo audio from user space and feeds the volume, equalizer, and DRC modules.

  2. Playback Delivery & Loopback Tapping: The DAI Copier transmits audio to physical speakers via Pin 0 while simultaneously tapping the identical signal onto Output Pin 1.

  3. Microphone Capture & Selection: The DAI Capture Copier ingests 4 channels from the digital microphone array. The Selector isolates the two primary front-facing microphones and drops the auxiliary background channels.

  4. Echo Reference Aggregation: The Multiplexer fuses the 2-channel microphone audio on Pin 0 with the 2-channel speaker loopback reference on Pin 1 into a synchronized 4-channel composite stream.

  5. Speech Enhancement & Delivery: Downstream Acoustic Echo Cancellation (AEC) and Time-Domain Fixed Beamforming (TDFB) cancel the speaker echo and beamform the user’s speech. The final clean audio stream is written into host memory by the Host Capture Copier.

Through this coordinated division of labor, Sound Open Firmware delivers modular, high-performance, and mathematically robust audio graphs across desktop, mobile, and embedded platforms.