# AudioReach: An End-to-End Solution

Patrick Lai

► To cite this version:

Patrick Lai. AudioReach: An End-to-End Solution. Proceedings of the 19th Linux Audio Conference, Jun 2025, Lyon, France. hal-05096016

HAL Id: hal-05096016

https://hal.science/hal-05096016v1

Submitted on 3 Jun 2025

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>
# AUDIOREACH™: AN END-TO-END AUDIO SOLUTION

Patrick Lai

Principal Software Engineer
Qualcomm Technologies, Inc., USA
plai@qti.qualcomm.com

## ABSTRACT

The AudioReach solution developed by Qualcomm Technologies, Inc. addresses significant obstacles in the audio development landscape. This paper explores the comprehensive capabilities provided by AudioReach, including off-target development, graphical design, testing, and deployment. The framework supports heterogenous or distributed processing and offers a unified environment for developing audio use cases across various processors and platforms. By open-sourcing AudioReach[1], Qualcomm Technologies aims to foster a community-driven project that enhances audio development efficiency and lowers costs for vendors, algorithm and system use case designers, tuning engineers, and system integrators.

## 1. INTRODUCTION

Qualcomm Technologies' diverse product portfolio spans both ends of the computing spectrum, from high performance to low cost (minimal power, cycle, and memory footprint). To support a broad range of audio and voice use cases across diverse SoCs, platforms, and product devices, a scalable and adaptable solution is essential. To facilitate the integration of various deliverables, including algorithms, system software, and tuning data, a developer-friendly solution is essential to empower multidisciplinary developers to seamlessly combine their contributions into a cohesive final product. Qualcomm Technologies has developed a comprehensive SDK to address these needs. An open-source project has also been initiated, recognizing the need for a community sponsored solution to fully address gaps in the existing open-source software landscape. This paper explores various aspects of the AudioReach SDK, including key software components and constructs, the development workflow it enables, and other aspects and highlights of the open-source project.

## 2. OPEN SOURCE PROJECT

In examining the open-source landscape, it is evident that there is no single solution addressing all the following needs:

* A unified, integrated environment for developing algorithms, signal flow graphs with interconnected processing modules, and system use cases.

* A comprehensive infrastructure for configuring, monitoring, tuning, and optimizing system use cases.

* A framework supporting distributed processing across heterogeneous CPU, MUC, and DSP cores or SoCs.

* Independent control of use cases in low-power and high-performance subsystems on the same device.

Later sections of the paper will dive into detail of AudioReach SDK so it would become apparent how SDK would address the gaps. Meanwhile, AudioReach has commercialized on many product lines including wearables, automobiles, handsets, Extended Reality, and computing devices which are built on sophisticated SoCs with both high performance and low power subsystems running different open-source and proprietary operating systems. The supported use cases on these devices include,

but are not limited to, typical audio playback, recording, circuit-switched calls, low-power voice UI functionalities, and always-on audio sensors. With wide product deployment and a rich set of capabilities, Qualcomm Technologies believes the community can benefit from the AudioReach SDK and has decided to open-source the solution as a community sponsored project. While detailed information about the project can be found in the project site, this paper highlights three key aspects:

* Given the portability of AudioReach, the project is not limited to Qualcomm® platforms but has also been (and will be) actively ported to non-Qualcomm platforms as part of the evolving project roadmap.

* The project has chosen the BSD-3-Clause Clear license to benefit the broader ecosystem.

* The project aims to be community-driven and seeks to establish a steering committee to collectively define the project's roadmap. To demonstrate our commitment to involving the community, Qualcomm Technologies is overhauling internal processes to facilitate public development.

AudioReach SDK is available as part of Qualcomm® Linux® Yocto and Ubuntu distribution. As for non-Qualcomm platforms, Yocto meta layer is available to enable AudioReach on Raspberry Pi while work is in progress to port to SoCs with Xtensa DSP. Please note that the current contribution is focused on Linux due to the open-source nature of Linux ecosystem. The scope of contributions will be broadened once AudioReach support is extended to other open-source operating systems such as Zephyr.

AudioReach open-source project is still in its infancy. While embedded software components and AudioReach Creator (GUI-based use case & tuning configuration tool) have been built up, figure 1 illustrates the proposed roadmap that includes plans to support additional third-party hardware, build up off-target development capabilities, integration with MathWorks tools, and release open-source OS-agnostic version of AudioReach Creator (ARC). Today, public/free version of ARC is distributed as Windows executable through Qualcomm developer network.

## 3. AUDIOREACH SDK

The AudioReach SDK includes software components for host and embedded devices, enables developers to design, simulate, and tune signal flow graphs in real-time. The solution supports interoperability with standard APIs and frameworks such as PulseAudio[3], and PipeWire[4]. AudioReach is highly portable, allowing developers to enjoy the same environment and workflow across different hardware and OS platforms.

### 3.1. Design Objectives

Prior to delving into the architecture and components of the SDK, it is essential to comprehend the primary design objectives that guide the AudioReach architecture and implementation.

#### Leveragability

* Portability across different SoC / HW vendor platforms using same development environment and workflow.
<figure><img src="image_2.png" /><figcaption>Figure 1: AudioReach roadmap</figcaption></figure>

* Interoperability with OS ecosystem software and tools

## Scalability

* Modularity that allows the same solution to scale up or down to with capabilities and limitations (e.g., cycle or memory constrained environments).

* Distributed processing across multiple heterogeneous cores and SoCs

## Extensibility

* Data driven customization minimizing coding and integration effort

* Extensible interfaces, use case logic, components, and signal processing framework elements

## Capability

* Common development environment and tooling across entire Single tool to enable full development workflow

## 3.2. High-level Architecture and Key Components

AudioReach is comprised of platform independent and platform dependent (adaptation layer) software spanning across host and embedded device as illustrated in Figure 2. AudioReach Creator (ARC), formerly known as Qualcomm® Audio Calibration Tool (ACT), is PC-based application exposing a GUI to the audio system designer for connecting processing modules into audio signal flow graphs, configuring, and storing graphs in an audio calibration database (ACDB). This database can be loaded into the device at run-time and used to configure signal flow graphs deployed across various audio and voice use cases. Furthermore, this database can be updated at run-time and used, in addition to ARC, by tuning and use case design engineers to tune, configure, and monitor audio and voice processing blocks in real-time. These capabilities are referred to as “real-time tuning and calibration (RTC)” and “integrated resource monitoring (IRM)”.

The AudioReach software components running on the embedded device in the Platform Adaptation Layer (PAL), graph services (ARGS), and AudioReach Processing Engine (ARE). The ARE includes a Signal Processing Framework (SPF) along with reference algorithms as shown in the diagram below. Depending on the SoC design, the ARE usually runs in the DSP subsystem running RTOS while audio platform software typically resides on the application subsystem running a high-level operating system such as Linux. Communication between ARGs and ARE is facilitated using an IPC protocol called Generic Packet Router (GPR).

Typically, applications developed for ubiquitous software platforms use standardized APIs and multimedia/audio frameworks. To align with these standardized APIs, a platform adaptation layer (PAL) is used to translate platform-specific APIs and constructs to ARGs APIs and constructs. In addition, ARGs and ARE is built on top of a platform and OS abstraction layer to allow the AudioReach solution to scale across different OS and hardware platforms.

<figure><img src="image_3.png" /><figcaption>Figure 2: Subsystem view</figcaption></figure>

## 3.3. High-level Software Flow

ARGS is the conduit between ACDB and the ARE. It manages the opening and closing of use case signal flow graphs and exchange of real-time audio and voice signal data, meta-data, and control / configuration data. As previously stated, ACDB stores audio signal flow graph connection information and calibration data. When a use case is launched (client requests a graph to be opened), ARGs retrieves and downloads the graph definition and calibration data from ACDB and delivers it to ARE using GPR. The ARE then constructs the signal flow graph using the processing module connection information provided and attaches that graph to applicable source and sink endpoints. The processing modules are attached or plugged into the ARE using a Common Audio Processing Interface (CAPI).
## 3.4. Fundamental concepts and Constructs

The AudioReach SDK is built on several core concepts and constructs, including module, audio graph, sub-graph, and containers as depicted in figure 3. Audio graph represents the interconnection of modules to achieve specific use cases, while sub-graphs are logical abstractions for groups of modules. Containers is the concept of ARE which allows system designers to group and execute audio processing modules together in a single software thread. In the graph definition, modules are assigned to run on specified CPU domains.

To load and configure signal flow graphs, AudioReach identifies graph, calibration data, and destination modules using a vector of keys and values (KV). Using ARC, the system designer associates a key-value vector to desired signal flow graph, which also attaches or tags calibration and other meta-data to modules within that graph.

<figure><img src="image_4.png" /><figcaption>Figure 3: Graph composition</figcaption></figure>

## 4. DEVELOPMENT WORKFLOW

Although off-target development capabilities are yet fully implemented as indicated in the project roadmap, AudioReach is envisioned to support a complete beginning to end workflow that includes off-target simulation and testing to on-target characterization, optimization, and verification. This off- to on-target development workflow facilitates a seamless, low effort migration to hardware platforms and devices running AudioReach, which reduces development cost and time-to-market for developers. As depicted in Figure 4, the typical development workflow using AudioReach includes the following basic steps while developers who already have IP in C can skip step 1 and 2:

1. Algorithm library development starts off-target, using standard algorithm design tools such as MATLAB/Simulink to design with a wealth of primitives, simulate, and automatically generate architecture optimized code

2. In System Composer, compose signal flow graph with algorithm libraries from Simulink, simulate, partition processing workload across cores based on simulation results, and auto generate CAPI-wrapped modules

3. A specific AudioReach development workspace is created in AudioReach Creator (ARC) by importing meta data from an existing product (ACDB, ARGs, ARE, and module configuration and header files) and/or netlist with AudioReach specific meta data from System Composer project if applicable

4. Import algorithm CAPI modules into Visual Studio Code and compile, using architecture-specific toolchain, as part of AudioReach simulation platform or loadable library which can be loaded into simulation platform dynamically

5. Use ARC to simulate, characterize, optimize, and validate use case designs including the algorithm modules on simulation platform before moving onto a given embedded device

6. Export use case data including graph configuration, calibration, tagging information out of ARC and into a target embedded device.

7. Once code and use case data is successfully imported into the target embedded device, ARC can be used to configure, tune, calibrate, and monitor the signal processing software in real-time. AudioReach also supports modifying the signal flow graph definitions (topology, parameters, et cetera) at run-time, obviating the need to rebuild (compile and link) the software and reboot the device.

<figure><img src="image_5.png" /><figcaption>Figure 4: Development workflow</figcaption></figure>

## 5. AUDIOREACH CREATOR

AudioReach Creator is a GUI based application that serves as the primary front-end for designers and developers to define, configure, optimize, monitor, and validate their system use cases. The key attributes of ARC include the following:

* Compose, configure, optimize, and store use case signal flow graph data into workspace and embedded audio configuration database (ACDB) files.

* Distribute sections of signal flow graph to different cores.

* Activate use cases in both off-target and on-target environments.

* Monitor and profile cycle and memory usage in real-time at different granularities (per module, per thread, per core).

* Coordinate loading of dynamically (run-time) modified signal flow graphs into embedded device without rebuilding or rebooting device.

* Dynamically tune audio and voice signal processing modules locally and remotely in both offline and real-time modes, including pushing modified parameters into persistent storage (ACDB) on the embedded device.

* Interoperate with multiple third-party tuning tools and applications using a published command line interface.

## 6. AUDIOREACH ENGINE

The AudioReach Engine (ARE) is a comprehensive signal processing framework (SPF) designed to manage a broad spectrum of audio and voice signal processing flows. It adopts a client-server model where the server executes algorithms and a client framework that bridges the high-level software stack and the server framework. Figure 5 illustrates high-level architecture of ARE. The platform and OS abstraction layer (POSAL) ensures the framework works on different processors and hardware architectures. The ARE consists of several functional blocks, including the Generic Packet Router (GPR), Audio Processing
Manager (APM), and Audio Module Data Base (AMDB). The GPR provides routing functionality for audio message packets across the ARE and ARGs. The APM is responsible for setting up and managing the use case graphs in the ARE. The AMDB provides the database of CAPI-wrapped topology and processing modules in the ARE.

ARE is a highly capable, flexible, and extensible framework. Signal processing modules are easily integrated into the framework using CAPI. The framework is modularized to support many different types of signal flow graphs, threading configurations, and end point types. ARE is equipped with an extensive range of capabilities, allowing the solution to span across a broad set of diverse products. As depicted in Figure 5, the following list of capabilities showcase the breadth and depth of the ARE solution:

* Supports fixed and floating point PCM data format, and various standard compressed data formats.

* Supports multiple scheduling modes and data delivery mechanisms.

* Supports multiple (independent or interdependent) instances of AREs across heterogeneous CPU, MCU, and DSP cores.

* Supports media format propagation across the processing modules in the signal flow graph.

* Supports metadata propagation across the signal flow graph (e.g., propagation of end-of-stream event).

* Supports dynamic loading of modules and entire signal flow graphs.

* Supports control link across modules to exchange messages, intents, or other meta-data.

* Supports partial tear down and incremental construction of signal flow graph which can be useful for device switch scenario.

* Supports flexible and configurable frame sizing across modules and containers.

* Supports inter-module and -container buffering to allow interconnection of modules designed for different frame sizes.

* Supports real-time calibration and processing data monitoring (signal, cycle, memory, etc.) or Integrated resource monitoring (IRM).

* Supports clock voting to optimize performance and power.

* Supports flexible placement of PCM data logging in signal flow graph.

## 7. AUDIOREACH GRAPH SERVICES

AudioReach graph services (ARGS) are a collection of cross-platform software libraries, as depicted in Figure 7, that provide the following services:

### Use Case Execution:

* Establish communication channel with AudioReach Engines (ARE)

* Set up and tear down audio graphs running on ARE for intended use cases

* Provide audio data interface to client to exchange audio data with ARE

* Provide control interface allowing client to apply control commands on intended modules in the audio graph

* Relay module event to client

* Apply calibration and other configuration data on the signal flow graph

* Monitor and recover from ARE faults and restart events

<figure><img src="image_6.png" /><figcaption>Figure 5: ARE high-level architecture</figcaption></figure>

### Development Workflow:

* Log audio samples or module-specific data at configurable points in the signal flow graph

* Perform real time tuning of audio processing modules running in ARE

* Download new calibration data to the device

* Monitor system and module resource in real-time

* Allow ARC to remotely trigger audio and voice use cases on the embedded device

AudioReach graph services, as depicted in Figure 6 below, include the following four cross-platform software components:

* Graph Service Library (GSL)

* ACDB Manager Library (AML)

* Generic Packet Router (GPR)

* Audio Tuning Service (ATS)

These components invoke utilities and obtain platform specific information provided by OS abstraction layer (OSAL) and platform wrapper in order to operate on the intended platform.

GSL serves as the entry point for a client to access functionalities provided by graph service and ARE. Through GSL APIs, a client can initiate graph setup, exchange audio data, and operate on the audio graph running on ARE. GSL queries AML using graph key vectors (GKV), calibration key vectors (CKV), and tag key vectors (TKV), which are passed by the client to retrieve graph definition, calibration, and tagged payloads. Then, GSL packetizes retrieved data from AML and invokes GPR to send commands and receive response from ARE. If modules running in the DSP can generate events, such as key word detection, GSL would relay the detection event back to client.

Apart from providing service to client, ARGs also plays a critical role in audio system development workflow. Audio tuning service works as bridge between ARC on host PC and rest of AudioReach software running on target. ATS dispatches commands from ARC to various service handlers which interfaces with rest of AudioReach software components to achieve development workflow use cases described in introduction section.
<figure><img src="image_7.png" /><figcaption>Figure 6: ARGs high-level architecture</figcaption></figure>

## 8. GENERIC PACKET ROUTER

The GPR infrastructure provides a common set of APIs across different platforms, software layers, and processor domains to enable them to communicate using asynchronous messages. The infrastructure is a memory optimized, platform agnostic layer. Figure 7 illustrates an example of the GPR infrastructure on different processor domains such as the application processor domain, DSP domain, and different OS platform such as Linux.

The GPR is responsible for routing messages and commands between the ARE and GSL processing domains in the AudioReach framework. It achieves this remote communication by abstracting out the underlying inter-processor communication (IPC) data link or transport layers, obviating need for system integrators implement platform specific solutions.

<figure><img src="image_8.png" /><figcaption>Figure 7: GPR on different processing domains</figcaption></figure>

## 9. AUDIOREACH FOR LINUX

AudioReach offers three architecture options for Linux as depicted in Figure 8. Option 1 follows the conventional architecture which Qualcomm Technologies has upstreamed its Au-

<figure><img src="image_9.png" /><figcaption>Figure 8: Linux support</figcaption></figure>

dioReach ALSA drivers into the Linux kernel under sound/soc/q-com/qdsp6. These drivers utilize ASOC topology support to give flexibility of building different use case topologies in DSP. Please note that option 1 supports limited use cases and is mainly targeted for developers who are accustomed to kernel sound card architecture.

Option 2 adheres to a conventional Linux audio userspace stack, in which PulseAudio or Pipewire operates on top of libALSA. Below this layer, the AudioReach SDK includes plugins that interact with ARGs residing in userspace instead of going into kernel sound card. The advantage of the AudioReach solution lies in its ability to offer a consistent development environment and software constructs, irrespective of the hardware and operating system platforms being targeted. By constructing this userspace architecture, it preserves the ecosystem API, thereby eliminating the necessity for existing applications to adapt to a new set of APIs, while simultaneously offering an enhanced feature set provided by AudioReach.

In cases where a product has concurrent use cases requiring dynamic reconfiguration as use cases are enabled and disabled, option 3 provides full stack support from PulseAudio/Pipewire and interfaces with the platform adaptation layer (PAL), utilizing plugins to manage a wide variety of use cases and sound devices efficiently.

To deploy option 2 or 3, one can find drivers and plugins for ALSA, PulseAudio within the AudioReach project while Pipewire plugins support is coming soon. We plan to engage with relevant ecosystem project communities to upstream these components. Our vision is to establish the AudioReach user-mode architecture as a viable alternative to the kernel architecture and integrate it directly into standard distributions.

## 10. CONCLUSIONS

The AudioReach SDK offers a solution for developing audio and voice applications across various platforms and devices. With the recent open-sourcing of AudioReach, the community now has access to a toolkit for creating feature-rich audio products. Though there is long road ahead to achieve envisioned development workflow, we hope audio developers like the project roadmap and can join the AudioReach community and contribute to its development. Please refer to AudioReach documentation site[2] to learn more about the project and SDK.

The Linux Foundation and The Linux Foundation logo design are registered trademarks of The Linux Foundation. Linux is a registered trademark of Linus Torvalds.
Qualcomm branded products are products of Qualcomm Technologies, Inc. and/or its subsidiaries.

Qualcomm Developer Network and Qualcomm Linux are programs of Qualcomm Technologies, Inc. and/or its subsidiaries.

Qualcomm is a trademark or registered trademark of Qualcomm Incorporated.

## 11. ACKNOWLEDGMENTS

Many thanks to my lead, Raymond Smith, and my colleague, Viktor Nikolic, for their contribution to this paper

Many thanks to my lead, Raymond Smith, for giving me the opportunity to start/lead AudioReach open-source project

Many thanks to Aditya Rathi, Annemarie Porter, Robin Gupta, Rohit Kumar who help me build up the project

Many thanks to all Qualcomm technologies audio developers who contribute to making of AudioReach SDK

## 12. REFERENCES

[1] "AudioReach", http://github.com/audioreach

[2] "AudioReach documentation", http://audioreach.github.io

[3] "PluseAudio Community", "PulseAudio", http://pulseaudio.org

[4] "Pipewire Community", "Pipewire", http://pipewire.org