QSA with QNX Acoustics Management Platform

Concurrent access on playback and capture paths

QNX AMP extends QSA with signal processing functionality using the io-audio Low-Latency Audio Architecture, into which one or more AMP Functional Modules (AFMs) are loaded.

Figure 1. AMP audio flow.

The low-latency software framework allows demanding applications such as In-Car Communication and Active Noise Control to be implemented on application processors rather than dedicated Digital Signal Processors (DSPs). It extends the existing audio infrastructure in QNX Neutrino in a completely backwards-compatible way so that applications such as telephony, speech recognition, navigation, and media playback all run entirely unmodified and interact positively with the acoustic signal processing functions of the system.

QNX AMP allows a single audio input and output hardware controller to service one or more microphones and one or more speakers for your target environment. In the automotive context, these are the cabin microphones and speakers. To be able to share these devices between modules/processes/threads concurrently, a PCM software mixer on the playback path mixes multiple audio streams into a single output audio stream that targets the main speakers, and a PCM input splitter on the capture path distributes and replicates the single microphone (mono or multichannel) audio stream to different modules/processes/threads. An example of concurrent access on the playback path is having the media player, the In Car Communications (ICC) module, and the QNX Acoustics for Voice (QAV) module concurrently writing audio to the playback device for one or more cabin speakers. An example on the capture path is having a voice recognition application, the ICC module, and the QAV module concurrently sourcing data from the capture device for one or more cabin microphones. Without the PCM software mixer for playback and the PCM input splitter for capture, only a single module/process/thread can access the hardware device at any given time.

LiveAMP and Acoustics Control Server (ACS)

QNX AMP includes LiveAMP, a set of tuning, diagnosis, and analysis tools that enables real-time adjustment of system parameters, signal streaming, and injection at multiple tap-points in the system, as well as real-time spectrum and waveform displays. AFMs are controlled remotely using the Acoustics Control Server (ACS), which links LiveAMP to the AFM modules in io-audio.

Supported audio devices

In addition to the audio devices supported by QSA, AMP supports the following additional device types:

AMP Functional Modules (AFM) devices (/dev/snd/afmCxDx)

AFMs are audio processing modules that connect to a PCM device in the digital domain to perform specialized audio processing functions. In most cases, an AFM is configured to source data from a PCM input splitter and sink data to a PCM software mixer. This configuration allows the AFM to run in parallel with other audio functions and applications using the same audio PCM hardware device. The snd_afm_* () APIs can be used to open and interact with an AFM.

PCM AFM

An AFM can create a PCM device to provide an application interface to AFM processing. This device simply appears as a new playback, capture, or playback and capture PCM device. Data written to this class of PCM playback device passes through the AFM processing algorithms before being passed to a PCM hardware or software mixer device. Data read from this class of PCM device is originally sourced from a PCM hardware or input splitter capture device and then passed through the AFM processing algorithms. PCM devices created by an AFM are always visible under /dev/snd, but may not always be usable by a client application. Generally, the AFM needs to be put into "PCM Mode" to make its corresponding PCM interface usable. If an application tries to use an AFM’s PCM interface when it is not in PCM mode, the call to snd_pcm_plugin_params() fails with EAGAIN.

Audio library

AMP is supported by the snd_afm_*() APIs. In addition to basic controls and status, they also provide an interface to input Vehicle Input (VIN) data from the CAN bus for use by AFMs. For more information, see Audio Library.

Configuring io-audio

The -c option for io-audio allows you to configure the low-latency software framework using a configuration file that is loaded at startup.

You use the configuration file to load the DLLs that provide QNX AMP functionality.

Audio devices are indexed based on the order in which their respective audio drivers are mounted in the io-audio process. Keep this in mind when you create your audio configuration file. The order of the [ctrl] sections determines the order in which the audio drivers are mounted into the io-audio process and thus determine the index of each audio device. Generally, this means you want the [ctrl] section for your main audio device (main microphone and speakers) to be the first [ctrl] section in the audio configuration file and any secondary audio devices (Bluetooth, radio tuner, and so on) to follow it. Because all AFMs connect to an audio device, you must list them after the [ctrl] sections in your configuration file.

Audio device indexing uses card and device numbers. Each [ctrl] or [afm] creates a card, with the card indices starting at 0 and incrementing for each section of [ctrl] or [afm] type. Each card has 0 or many devices under it.

You can use the [acs] section in the audio configuration file to load the dev-acs-link DLL. This DLL creates an afm entry point and instantiates the ACS link.

See io-audio in the Utilities Reference for a detailed description of io-audio configuration file.