Table of Content

Audio Object Developers Guide

  1. Purpose of this Document
    1. Terms and Abbreviations
    2. Requirements
  2. Overview
    1. Audio Object Workflow
    2. Audio Object Class
  3. Audio Object Configuration
    1. Design Time Configuration
    2. Advanced Design Time Configuration
  4. Basic Features and APIs
    1. Constructor
    2. GetSize
    3. Init
    4. Calc
    5. TuneXTP
    6. Control
  5. Advanced Features and APIs
    1. Audio Object Additional Configuration
    2. Audio Object Sub Blocks
    3. Audio Object AO Switch Processing State
    4. Debug and Monitoring
    5. Background Method
  6. Audio object Examples
    1. Example 1 - AwxAudioObjExt.cpp
    2. Example 2 - AwxAudioObjExtToolbox.cpp
    3. Example 3 - AwxAudioObjExtMemRecs.cpp
    4. Example 4 - AwxAudioObjExt.h
    5. Example 5 - AwxAudioObjExtToolbox.h
    6. Example 6 - AwxAudioObjExtMemRecs.h
  7. General Guidelines
    1. Hardware Abstraction
    2. Hardware Abstraction for Header files
    3. Memory Enums
    4. Overlays
  8. Adding external audio object into AudioworX package
    1. Building External AO

Device Description File

  1. Terms and Abbreviations
  2. Purpose of this Document
  3. Root Element
  4. Node Elements
    1. Communication Parameters
    2. Identification of Target Device
  5. Virtual Device
  6. Objects
    1. Object
    2. Definition of a Table Object
    3. Definition of a Biquad Coefficients Object
  7. StateVariables
    1. Common
    2. NumericalSV
    3. EnumSV
    4. FilterTypeSV
    5. FloatArraySV
    6. Float16ArraySV
    7. FixedPoint16ArraySV
    8. StringSV
    9. FixedPointM_NArraySV
  8. TargetValue
    1. Common
    2. Target Value
    3. Block Target Value
  9. Templates
    1. StateVariables
  10. Revision History

Griffin Reference Projects User Guide

  1. Terms and Abbreviations
    1. Multi dll support for CAO
    2. Tuning Panel Compound Audio Object
  2. Purpose Of This Document
    1. Apply tuning to Compound Audio Object Template
    2. Testing New Post 2025

7.1.Hardware Abstraction

Hardware abstraction is being done at Audio Object functions level such as calc, init etc.

Audio Object Function Level Abstraction

When the audio object function implementations are significantly different across various platforms, platform specific functions should be in different cpp files (file per core). A new cpp file needs to be introduced for every object that has any core-specific code. The object will still have one header file across all platforms. Dll specific functions should be part of Win32 specific files.

Folder Structure

The folder structure will look like the following:

Override Defines

Each object will also have an “OBJECT”_OVERRIDE define. This define may be in the object header. However, for the xAF basic audio objects and the core objects, they have been combined into buildprocessor”PLATFORM”objectOverride”PLATFORM“.cmake file that shall be included in the build process.

For non-Sharc platforms, the API function specific defines are available in AudioFramework.h and the Biquad specific defines are available in privatesrcframeworkfilterCMakeLists.txt:

For example, buildprocessorarmv8aobjectOverrideArmv8a.cmake will look like the following:

For SHARC based platforms, it is not possible to define the override macro as a logical expression of individual API macros as done above. Here the logical operation is done separately with the math directive and subsequently assigned to the overriding macro. Both the API function specific defines and the Biquad specific defines are available in this file buildprocessorsharcobjectOverrideSharc.cmake:

The FIR object has Sharc specific implementation for init() and calc(). The FIR_OVERRRIDE define will be the union of XAF_INIT and XAF_CALC defines as given below:

Files

In the generic implementation of the object, every function that is overridden in optimization files should be surrounded by an ifdef check. Using the example above, the generic file FIR.cpp would look like this:

The Sharc file – FIRSharc.cpp – in this case should override both init() and calc():

Build System

Based on the target processor, the build system should always include the generic cpp implementation and the processor specific implementation. For example, when compiling for Sharc for the xAF basic audio objects:

Generic Files

SHARC files

Last updated on October 24, 2024
« General GuidelinesHardware Abstraction for Header files »
Help Guide Powered by Documentor
Suggest Edit