Home
QNX Software Development Platform
QNX SDP is a cross-compiling and debugging environment, including an IDE and command-line tools, for building binary images and programs for target boards running QNX Neutrino 7.1.
Audio & Graphics API
Audio Developer's Guide
The Audio Developer's Guide is intended for developers who want to write audio applications using the QNX Sound Architecture (QSA) drivers and library.
Audio Concurrency Management
You can manage multiple audio streams using various audio policies.

QNX Momentics IDE User's Guide
This User's Guide describes version 7.1 of the Integrated Development Environment (IDE) that's part of the QNX Momentics tool suite.
QNX Software Development Platform
QNX SDP is a cross-compiling and debugging environment, including an IDE and command-line tools, for building binary images and programs for target boards running QNX Neutrino 7.1.
- Quickstart Guide
- OS Components & Operations
- Audio & Graphics API
  - Audio Developer's Guide
    The Audio Developer's Guide is intended for developers who want to write audio applications using the QNX Sound Architecture (QSA) drivers and library.
    - Audio Architecture
      This chapter includes information about QNX Sound Architecture (QSA), sounds cards and devices, sound card control devices, mixers, and pulse code modulation (PCM).
    - Playing and Capturing Audio Data
      This chapter describes the major steps required to play back and capture (i.e., record) sound data.
    - Mixer Architecture
      This section describes the mixer architecture.
    - Audio Concurrency Management
      You can manage multiple audio streams using various audio policies.
      - Understanding audio ducking
        When audio ducking is enabled, all audio streams adhere to an audio ducking policy that's defined in the audio policy configuration file.
      - Understanding volume ramping
        Volume ramping (or simply ramping) allows you to control volume changes.
      - Understanding preemption
        Preemption is an optional policy that you can apply to an audio type. It determines whether the audio stream is suspended when its volume is ducked to zero.
      - Understanding audio type volume controls
        Each audio concurrency management context defined in your system has an associated mixer device created under an audio management card. The mixer device for your audio concurrency management context contains mixer groups for each audio type defined in the context’s audio policy configuration file. You can use the standard snd_mixer_group_*() APIs to read and write volume and mute settings of these mixer groups, which allows for synchronous adjustments of the volume and mute levels of all audio streams of the specified audio type.
      - Syntax of the audio policy configuration file
        Audio policy configuration files have a specific syntax.
    - Optimizing Audio
      Here are some tips for reducing audio latency:
    - Audio Library
      This chapter describes all of the supported QNX Sound Architecture (QSA) API functions, in alphabetical order; undocumented calls aren't supported.
    - afm_ctl.c example
      This is the source for the afm_ctl utility.
    - apx_ctl.c example
      This is the source for the apx_ctl utility.
    - wave.c example
      This is a sample application that plays back audio data.
    - waverec.c example
      This is a sample application that captures (i.e., records) audio data.
    - mix_ctl.c example
      This is a sample application that captures the groups and switches in the mixer.
    - audiomgmt_monitor.c example
      This is a sample application shows how to get the current active audio types.
    - ALSA and libasound.so
      The only supported interface to the ALSA 5 drivers is through libasound.so. Direct use of ioctl() commands isn't supported because of the requirements of the ALSA API. It uses ioctl() commands in ways that are illegal in the QNX Neutrino RTOS (e.g., passing a structure that contains a pointer through an ioctl()).
    - Glossary
  - Gestures Library Reference
    The Gestures library provides gesture recognizers to detect gestures through touch events that occur when you place one or more fingers on a touch screen.
  - Image Library Reference
  - Input Events Library Reference
    The Input Events library provides the framework necessary for Screen Graphics Subsystem to communicate with your touch driver.
  - OpenWF Configuration Developer's Guide
    If you are integrating a new display, you must configure and provide the parameters of your display based on its specifications via the OpenWF Display Configuration API (Wfdcfg Library).
  - Screen Graphics Subsystem Developer's Guide
    QNX Screen Graphics Subsystem is a graphics framework that provides all the functionality necessary to develop interactive user experiences.
  - Video Capture Developer's Guide
    The video capture framework provides applications the ability to capture frames from a video input source. These frames can be passed to a graphics component such as Screen for display.
- Multimedia
- Networking Middleware
- Programming
- Sensor Framework
- System Security Guide
  The QNX System Security Guide is intended for both system integrators who are responsible for the security of a QNX Neutrino RTOS system and developers who want to create a QNX Neutrino resource manager free from vulnerabilities.
- Utilities & Libraries
QNX Hypervisor
The QNX Hypervisor allows you to run multiple OSs on a target system so you can separate critical and non-critical functions, support a wide variety of applications, and reduce hardware costs.
QNX Software in the Cloud
QNX Software in the Cloud enables developers to use the QNX software in Amazon Web Services (AWS) and Microsoft Azure (Azure).
QNX Advanced Virtualization Frameworks User's Guide
This User's Guide is aimed at all systems integrators and developers who want to design and build embedded systems using the QNX Advanced Virtualization Frameworks.
Typographical Conventions, Support, and Licensing
This section describes the typographical conventions used throughout the documentation and explains how to obtain technical support.

Audio Concurrency Management

You can manage multiple audio streams using various audio policies.

The policies control the following audio concurrency management features:

Audio ducking (referred to as simply ducking) manages concurrent audio playback where playing one audio stream lowers the volume of another stream. Whether one audio stream causes another stream to duck (lower in volume) is determined by priorities that you configure.
Audio ramping (referred to as simply ramping) gradually increases or decreases the volume of an audio stream so that it fades in or fades out. This effect makes ducking less abrupt.
When audio preemption (or preemption) is configured and the system ducks an audio stream, it also temporarily suspends the playing of that stream. You specify preemption options by audio type.
Audio type volume controls allow you to apply volume settings to all audio streams of a particular audio type.

You configure audio policies in the audio policy configuration file, which you specify using policy_conf in the [AUDIOMGMT] section of the audio configuration file. Each audio concurrency management context has its own audio policy configuration file and associated mixer device.

If your application needs to monitor the system's audio concurrency management changes, you can use control events. For more information, see Control events in the Audio Architecture chapter of this guide.

Page updated: March 12, 2026