Real-time AI voice processing in the Android audio HAL on Snapdragon 8 Elite

Why put voice processing in the audio HAL

Most voice effects live inside a single app. That's fine for that app, but a voice changer, a noise filter or a voice enhancer is often something you want everywhere: calls, voice notes, streaming and recording.

On Android, every app's microphone audio passes through the audio HAL, the vendor layer between Android's audio framework and the hardware. Processing there means apps don't need to change anything, and the device maker controls the experience.

The catch is that the HAL is vendor code. On Snapdragon devices it's Qualcomm's, it's built around Qualcomm's own effects, and it has to work with the phone maker's prebuilt libraries.

The build

We started with a OnePlus 13, which runs on Qualcomm's Snapdragon 8 Elite. On it we run a custom Android 16 build based on LineageOS, with Qualcomm's open-source audio HAL.

The effect is a third-party AI voice changer. It combines classic DSP voice effects with AI voices, and its AI models run on the Hexagon NPU through Qualcomm's QNN runtime (part of QAIRT), called from ONNX Runtime.

We registered it on the main recording paths, including the one VoIP apps use. Apps open the microphone as usual and get the changed voice back, with no code changes on their side.

How the audio flows

Audio leaves the microphone, passes through the audio DSP and Qualcomm's platform layer, and reaches the HAL. There, each recording buffer goes to the voice changer and back before Android hands it to the app.

What it took

Getting a third-party effect into Qualcomm's recording path meant working across several layers of the stack.

• A software path in a DSP-first HAL. Qualcomm's HAL hands effects like echo cancellation and noise suppression to the audio DSP. We added a path that runs a software effect on every recording buffer, inside the HAL, in real time.

• Matching the phone maker's binaries. The open-source HAL has to work with OnePlus's prebuilt audio libraries, including AudioReach's platform layer (PAL). Device IDs and interface versions had to match exactly what those libraries expect.

• The right NPU runtime. The phone ships its own, older QNN libraries. We made sure the voice changer loads the QNN version it was built for, so its models run on the NPU.

• A real-time budget. The HAL has to hand every buffer to the app on time. Each buffer gets a fixed time limit in the effect, and if the effect is late, the original audio goes through instead of stalling the recording.

What this means for device makers

Snapdragon chips now power phones, XR headsets, PCs, cars and IoT boards like Qualcomm's Dragonwing IQ series. Many of these devices need custom audio on the microphone path: voice effects, noise reduction, speech recognition or other AI models.

This project shows we can take third-party audio processing and run it at the platform level on Snapdragon: in the audio HAL, alongside the OEM's binaries, with AI inference on the NPU.

Our Switchboard SDK already runs on Android and on Linux ARM64, including Ubuntu and Yocto-based systems. That means the same audio pipeline can move from a phone to an embedded Linux board. If you're building a Snapdragon device and need audio processing at the system level, get in touch. We'd be glad to help.

FAQ

Can you run AI audio models on the Snapdragon NPU? Yes. Qualcomm's QNN runtime, part of QAIRT, runs models on the Hexagon NPU. ONNX Runtime can use it through its QNN execution provider, which is how the voice changer in this project runs its AI voices.

Where should system-wide voice processing go on Android? In the audio HAL, as a recording effect. Every app that opens the microphone gets the processed audio, and no app needs to change.

What is AudioReach? AudioReach is Qualcomm's open-source audio framework. It covers the audio DSP and the software layers above it, including the platform layer (PAL) that the audio HAL talks to.

Can the same processing run on Qualcomm IoT boards like the Dragonwing IQ-9075? Those boards run Ubuntu or Qualcomm Linux instead of Android. The Switchboard SDK builds for Linux ARM64, so the processing itself carries over. NPU acceleration and the board's audio setup are worked out for each platform.