AudioReach Architecture Overview
+AudioReach Architecture Overview
Guiding Principles
+Guiding Principles
Before drilling down into architecture overview, it is important to know the guiding principles which help shape AudioReach design and implementation
Unified software and software interface leveraged across wide range of hardware and software platforms
@@ -105,16 +103,17 @@
Guiding Principles
-Architecture Walkthrough
+Architecture Walkthrough
AudioReach is comprised of platform independent and platform adaptation software spanning across host PC and embedded device. AudioReach Creator(ARC), also known as Qualcomm Audio Calibration Tool (QACT), is PC-based software providing GUI to audio system designer for composing, configuring, and storing audio graphs into audio calibration database(ACDB) for intended use cases. In addition to use cases design, tuning engineer can tune the audio processing blocks through ARC and store the calibration into the same ACDB on the embedded device.
On the embedded device, AudioReach offers audio platform software and AudioReach Engine (ARE). ARE comprises Signal Processing Framework (SPF) along with reference algorithms as depicted in the diagram below. Depending on the SoC design, audio platform software usually resides on application subsystem running high-level operating system such as Linux and ARE resides in audio DSP subsystem running RTOS. Audio platform software is consisted of a set of libraries referred as AudioReach graph services(ARGS) and platform adaptation layer.
On many OS platforms, there are already application ecosystem built up based on well-established APIs and audio/multimedia frameworks. In order to meet the ecosystem need, platform adaptation layer is made available to translates platform specific APIs and constructs then calls into graph service.
Graph service provides the service to establish/tear down/operate/exchange audio samples & calibration data with the audio graphs running on ARE. As previously described, ACDB contains the audio graph definition and calibration data. Graph service, upon receiving graph open request from the client, retrieves audio graph and calibration data with use case handle and calibration handle from ACDB and downloads the graph definition and corresponding calibration data to ARE via generic packet router(GPR) protocol over physical or soft data link. On the receiving end, ARE forms audio graph with processing modules according to the graph definition and processes audio data piped from source endpoint to sink endpoint of audio graph.
Note that graph service and ARE are designed to be cross-platform software, platform/OS abstraction layer for different OS platforms would have to be developed in order to provide execution environment for graph service and ARE to run on.
-
+
+
-AudioReach High-Level Software Component View
+AudioReach High-Level Software Component View
+
+
AudioReach High-Level Software Component View
+AudioReach High-Level Software Component View
AudioReach Graph Services
+AudioReach Graph Services
Introduction
+Introduction
AudioReach graph services (ARGS) are a collection of cross-platform software libraries which together provide following services
Use Case Execution:
-
@@ -122,23 +120,24 @@
Architecture
+Architecture
Overview
+Overview
AudioReach graph services, as depicted below, is consisted of four cross-platform software components: Graph Service Library(GSL), ACDB Manager Library(AML), Generic Packet Router(GPR), and 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 intended platform.
GSL serves as entry point for client to access functionalities provided by graph service and ARE. Through GSL APIs, client can initiate graph setup, exchange audio data, and operate on the audio graph running on ARE. GSL queries AML with GKV, CKV, and TKV which are passed by the client to retrieve graph definition, calibration, and tagged payload. Then, GSL packetizes retrieved data from AML and invokes GPR to send commands and receive response from ARE. If module running in DSP is capable of generating event 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.
+
+
AudioReach Graph Services Block Diagram
+AudioReach Graph Services Block Diagram
Graph Service Library
+Graph Service Library
Functionalities
+Functionalities
Loading and Initialization of Sub-Graphs and Graphs via Graph Key Vector.
Graph setup and Dynamic handling of the sub-graphs within the graph
@@ -148,7 +147,7 @@ API Layer: GSL API layer defines and exposes APIs to GSL Clients. It provides API’s to query graph handle from use-case key vector information and also graph management etc. Full List of APIs are listed in Graph Service Layer.
@@ -179,17 +178,17 @@
Functionalities
-Compositions
+Compositions
Compositions
-ACDB Management Library
+ACDB Management Library
AML provides both get/set APIs to retrieve and adjust data in the ACDB DATA files. It provides data abstractions and organization for how calibration data is to be consumed by its client, GSL.
On device, there are ACDB file and ACDB delta file. ACDB file stores baseline calibration data needed by GSL and ARE in compressed binary form. Delta file contains data set by GSL and ARC during run time.
These files are managed by corresponding file managers as part of AML.
Compositions
-ACDB Management Library
+ACDB Management Library
AML provides both get/set APIs to retrieve and adjust data in the ACDB DATA files. It provides data abstractions and organization for how calibration data is to be consumed by its client, GSL.
On device, there are ACDB file and ACDB delta file. ACDB file stores baseline calibration data needed by GSL and ARE in compressed binary form. Delta file contains data set by GSL and ARC during run time.
These files are managed by corresponding file managers as part of AML.
Generic Package Router
+Generic Package Router
Refer to Functional Overview for high level overview of GPR.
Audio Tuning Service
+Audio Tuning Service
When ARC is connected to device, ARC is considered in connected mode. Communication is established with ATS via supported transport layer such as TCP/IP. Upon receiving ARC commands, ATS routes the commands to responsible service modules:
Online Calibration Service (OCS): The Online Calibration service allows ARC to operate portions of AML
@@ -200,7 +199,7 @@
Audio Tuning ServiceATS, beside depending on OSAL for OS related functionalities, relies on platform wrappers to provide platform specific utilities such as TCP/IP connection, playback/recording APIs.
Operating System Abstraction Layer
+Operating System Abstraction Layer
In order to run AudioReach graph services on desired OS platform, OSAL implementation shall provide the following functionalities:
Signal, Sleep, Thread, Mutex
diff --git a/docs/design/arspf_design.html b/docs/design/arspf_design.html
index 0dcc1ae..e0c9493 100644
--- a/docs/design/arspf_design.html
+++ b/docs/design/arspf_design.html
@@ -1,25 +1,22 @@
+
+
-
+
-
+
- AudioReach Graph Services
- Generic Packet Router
- Linux Adaptation Design +
- AudioReach Creator Design
AudioReach Engine
+AudioReach Engine
Introduction
+Introduction
This page walks through the high-level software requirements and design details of the AudioReach Engine (ARE) used in the context of the AudioReach™ architecture. Refer to Acronyms and terms for definition of acronyms used in this page
Overview
+Overview
High-level architecture
+High-level architecture
ARE follows client-server model where a server provides various functionalities, like realizing audio use cases, per the client requirements.
@@ -214,39 +212,42 @@High-level architect
Below figure illustrates the high-level software architecture used in
typical audio embedded systems.
-
+
+
-High-level audio software architecture
+High-level audio software architecture
+
+
High-level audio software architecture
+High-level audio software architecture
Possible use cases
+Possible use cases
The ARE can be used in various audio and voice use cases. This section includes, but is not limited to, the following high-level examples. Detailed use cases are illustrated in Use cases section.
Audio capture and recording
+Audio capture and recording
Audio capture involves the encoding of PCM data coming from a mic or any real-time device (end-point).
Audio formats used for encoding are: PCM, AAC, WMA std, AMRWB, and so on.
+
+
Audio renderer and playback
+Audio renderer and playback
Audio playback involves the decoding of given audio data, and playing the PCM on a speaker or any real-time device.
Typical audio formats used for decoding are: PCM, MP3, AAC, FLAC, ALAC, AC3, EAC3, Vorbis, WMA std, WMA Pro, DTS, APE, and so on.
+
+
Voice over IP (VoIP)
+Voice over IP (VoIP)
Voice over Internet Protocol (VoIP) involves both playback and record paths simultaneously, and it is used for voice communication.
Encoder and decoders interact with the host processor application that @@ -255,19 +256,21 @@
Voice over IP (VoIP)
-
+
+
Audio transcoding
+Audio transcoding
Audio transcoding involves converting one audio format to another. For example, from MP3 to AAC.
+
+
Audio loopback
+Audio loopback
Audio loopback involves receiving the data from one audio source and rendering it on an audio sink after optional processing.
An audio loopback is used in various scenarios like mixing the side tone @@ -283,26 +286,28 @@
Audio loopback
-
+
+
Audio detection
+Audio detection
Audio detection involves receiving the data from an audio source, processing it to improve the signal quality, detecting the intended attribute or event, and informing the registered clients.
Audio detection is used in various scenarios like DTMF detection, keyword detection, audio context detection, and so on.
+
+
Framework requirements
+Framework requirements
General
+General
Must be processor and platform agnostic.
Must be use case agnostic and data driven.
@@ -321,7 +326,7 @@
General
Client interfaces
+Client interfaces
Must support client-server communication in the same processor, across the processors, or across the processing domains.
@@ -341,7 +346,7 @@
Client interfaces
Processing chains, topologies, and graphs
+Processing chains, topologies, and graphs
Must support linear processing graphs (where modules are connected sequentially one by one).
@@ -370,7 +375,7 @@
Processing chains, t
Media formats
+Media formats
Must support the fixed and floating point PCM data format.
Must support various standard compressed data formats and the generic @@ -382,7 +387,7 @@
Media formats
Scheduling methods
+Scheduling methods
Should support different scheduling modes and different data delivery mechanisms (buffer availability, timer scheduled trigger, timed @@ -392,7 +397,7 @@
Scheduling methods
Resource management
+Resource management
Must provide the methods to manage the processing resources (memory management, processor cycles, band width, thread priorities, and so @@ -406,7 +411,7 @@
Resource management<
Debugging
+Debugging
Must provide the methods to log the diagnostic messages.
Must provide the option to log the audio data (PCM and compressed) at @@ -417,22 +422,23 @@
Debugging
ARE components
+ARE components
High-level architecture of the ARE
+High-level architecture of the ARE
+
+
ARE high-level architecture
+ARE high-level architecture
Functional blocks
+Functional blocks
This section provides a high-level overview of the functional blocks used in the ARE.
Generic Packet Router (GPR)
+Generic Packet Router (GPR)
The Generic Packet Router (GPR) provides the routing functionality for audio message packets (control, data, events, responses) across the ARE (server framework) and Graph Service Library (GSL; that is, the client @@ -444,16 +450,18 @@
Generic Packet Router (GPR)
-
+
+
-GPR header format
+GPR header format
-Opcodes
+Opcodes
All opcodes are to follow the GUID format.
-
+
+
Owner – Indicates the owner of the GUID, that is, whether the
@@ -467,18 +475,19 @@
Opcodes
-Messaging between ARE and GSL
+Messaging between ARE and GSL
The ARE supports two types of messaging approaches for optimal system
performance: in-band and out-of-band messages.
-
+
+
-In-band and out-of-band messaging methods
+In-band and out-of-band messaging methods
-In-band messages
+In-band messages
Contain the actual payload/message as part of the GPR payload.
The GPR forwards the full packet (that is, GPR header + actual
@@ -492,7 +501,7 @@
In-band messages
-Out of band messages
+Out of band messages
-Modules
+Modules
A module is an addressable functionality in the ARE.
A module ID is used to identify the functionality, and it is useful
@@ -521,7 +530,7 @@
Modules
-Control modules
+Control modules
Control modules provide the public interfaces to the clients (like GSL,
Codec Driver, and so on) to control the ARE resources and
functionalities (each module acts like service that provides specific
@@ -531,7 +540,7 @@
Control modules
-Data processing modules
+Data processing modules
Data processing modules can be static or dynamic, and they are typically
wrapped with the Common Audio Processing Interface (CAPI). The CAPI
interface acts as the bridge between the framework and core module
@@ -548,19 +557,20 @@
Data processing modules
-Links and connections
+Links and connections
Links and connections are used to connect the data processing modules to
create the use case graphs or chains. Originating and terminating points
of the link are represented by port.
Two types of links are used in the ARE: control links and data links.
-
+
+
-CAPI-wrapped modules with control or data links
+CAPI-wrapped modules with control or data links
-Control links
+Control links
Control links are bi-directional, point-to-point, and dynamic (variable
in number) or static (fixed in number with a specific label on the
control port).
@@ -571,7 +581,7 @@ Control links
-Data links
+Data links
Data links are unidirectional, point-to-point, dynamic (variable in
number, for example, input to the accumulator module can be variable),
or static (fixed in number with a specific label on the data port, for
@@ -584,7 +594,7 @@
Data links
-Graph and subgraph
+Graph and subgraph
A graph is the interconnection of a list of data path modules (with
input and output ports) to achieve an end-to-end use case.
A subgraph is like a graph and is used to represent a section (to
@@ -602,14 +612,15 @@
Graph and subgraph
-Containers
+Containers
A container is a framework implementation that helps in executing a
group of data processing modules in the same software thread. Following figure
illustrates this concept.
-
+
+
-Containers
+Containers
@@ -628,7 +639,7 @@ Containers
-Generic container
+Generic container
Supports hardware end-point/signal triggered modules, shared memory
end‑points, encoders, decoders, packetizers, depacketizer,
@@ -672,7 +683,7 @@
Generic container
-Specialized container
+Specialized container
Mainly designed for PP modules, including complex modules like rate
matching and multi-port modules such as EC, which need syncing
@@ -724,7 +735,7 @@
Specialized container
-Off-load container
+Off-load container
Supports reduction of the processing load on the local process domain
by helping to off-load an intended module or a group of data
@@ -771,9 +782,10 @@
Off-load container
-
+
+
-Example dataflow across containers
+Example dataflow across containers
When the use case is started with the default trigger policy:
@@ -797,7 +809,7 @@ Off-load container
-Audio Processing Manager (APM)
+Audio Processing Manager (APM)
The Audio Processing Manager (APM) is responsible for setting up and
managing the use case graphs in the ARE.
As illustrated in Figure: Audio Processing Manager, the APM provides generic public interfaces
@@ -816,28 +828,30 @@
Audio Processing Manager (APM)
-
+
+
-Audio Processing Manager
+Audio Processing Manager
The APM also handles the commands for controlling a subgraph’s state
machine:
-
+
+
-APM state machine
+APM state machine
-CLOSED
+CLOSED
The logical/non-existent graph state before OPEN and after CLOSE.
-STOPPED
+STOPPED
The state after the graph is opened or transitioned from STARTED as
part of STOP.
@@ -848,7 +862,7 @@ STOPPED
-PREPARED
+PREPARED
The media format is propagated through a module topology, if
available.
@@ -856,7 +870,7 @@ PREPARED
-STARTED
+STARTED
Platform-specific resources (MIPS, bus bandwidth, and so on) are
voted.
@@ -866,7 +880,7 @@ STARTED
-SUSPENDED
+SUSPENDED
Platform-specific resources (MIPS, bus bandwidth, and so on)
de-voted.
@@ -890,13 +904,14 @@ SUSPENDED
-Audio Module Data Base (AMDB)
+Audio Module Data Base (AMDB)
The Audio Module database (AMDB) provides the database of CAPI-wrapped
modules (both static and dynamic modules) in the ARE.
-
+
+
-Audio Module Data Base
+Audio Module Data Base
The AMDB is responsible for the following operations.
@@ -915,7 +930,7 @@ Audio Module Data Base (AMDB)Audio Module Data Base
-Built-in modules
+Built-in modules
Modules that are built with the ARE, both static and dynamic objects.
The AMDB uses the module database (module ID, entry point functions
@@ -924,7 +939,7 @@
Built-in modules
-Custom modules
+Custom modules
-Static Modules
+Static Modules
Static modules are loaded at boot time along with the ARE.
-Dynamic Modules
+Dynamic Modules
Depending on the memory and latency tradeoffs, dynamic modules can be
loaded at boot time or at a use case boundary.
-Integrated Resource Monitor (IRM)
+Integrated Resource Monitor (IRM)
The Integrated Resource Monitor (IRM) provides the profiling metrics for
different resources in the underlying platform.
The ARC platform displays resource metrics (MIPs, bandwidth, heap
usage, and so on) for system designers.
-
+
+
-Integrated Resource Monitor
+Integrated Resource Monitor
-Platform and OS Abstraction Layer
+Platform and OS Abstraction Layer
The platform and operating system abstraction layer (POSAL) provides the
necessary abstraction to the framework and makes it processor (hardware)
or platform (software) agnostic.
@@ -986,20 +1002,21 @@ Platform and OS Abstraction Layer
-Calibration and configuration
+Calibration and configuration
Calibration and configuration comprise the control information provided
to the module at setup and runtime to control the module’s
functionality.
-
+
+
-Calibration modes
+Calibration modes
Following are the three types of calibration interfaces exposed by the
AudioReach Engine.
GPR header format
+GPR header format
Opcodes
+Opcodes
All opcodes are to follow the GUID format.
+
+
Owner – Indicates the owner of the GUID, that is, whether the @@ -467,18 +475,19 @@
Opcodes -
Messaging between ARE and GSL
+Messaging between ARE and GSL
The ARE supports two types of messaging approaches for optimal system performance: in-band and out-of-band messages.
-
+
+
- In-band and out-of-band messaging methods
+In-band and out-of-band messaging methods
In-band messages
+In-band messages
Contain the actual payload/message as part of the GPR payload.
The GPR forwards the full packet (that is, GPR header + actual @@ -492,7 +501,7 @@
In-band messages -
Out of band messages
+Out of band messages
Modules
+Modules
A module is an addressable functionality in the ARE.
A module ID is used to identify the functionality, and it is useful @@ -521,7 +530,7 @@
Modules -
Control modules
+Control modules
Control modules provide the public interfaces to the clients (like GSL, Codec Driver, and so on) to control the ARE resources and functionalities (each module acts like service that provides specific @@ -531,7 +540,7 @@
Control modules -
Data processing modules
+Data processing modules
Data processing modules can be static or dynamic, and they are typically wrapped with the Common Audio Processing Interface (CAPI). The CAPI interface acts as the bridge between the framework and core module @@ -548,19 +557,20 @@
Data processing modules
Links and connections
+Links and connections
Links and connections are used to connect the data processing modules to create the use case graphs or chains. Originating and terminating points of the link are represented by port.
Two types of links are used in the ARE: control links and data links.
+
+
CAPI-wrapped modules with control or data links
+CAPI-wrapped modules with control or data links
Control links
+Control links
Control links are bi-directional, point-to-point, and dynamic (variable in number) or static (fixed in number with a specific label on the control port).
@@ -571,7 +581,7 @@Control links
-Data links
+Data links
Data links are unidirectional, point-to-point, dynamic (variable in
number, for example, input to the accumulator module can be variable),
or static (fixed in number with a specific label on the data port, for
@@ -584,7 +594,7 @@
Data links
-Graph and subgraph
+Graph and subgraph
A graph is the interconnection of a list of data path modules (with
input and output ports) to achieve an end-to-end use case.
A subgraph is like a graph and is used to represent a section (to
@@ -602,14 +612,15 @@
Graph and subgraph
-Containers
+Containers
A container is a framework implementation that helps in executing a
group of data processing modules in the same software thread. Following figure
illustrates this concept.
-
+
+
-Containers
+Containers
@@ -628,7 +639,7 @@ Containers
-Generic container
+Generic container
Supports hardware end-point/signal triggered modules, shared memory
end‑points, encoders, decoders, packetizers, depacketizer,
@@ -672,7 +683,7 @@
Generic container
-Specialized container
+Specialized container
Mainly designed for PP modules, including complex modules like rate
matching and multi-port modules such as EC, which need syncing
@@ -724,7 +735,7 @@
Specialized container
-Off-load container
+Off-load container
Supports reduction of the processing load on the local process domain
by helping to off-load an intended module or a group of data
@@ -771,9 +782,10 @@
Off-load container
-
+
+
-Example dataflow across containers
+Example dataflow across containers
When the use case is started with the default trigger policy:
@@ -797,7 +809,7 @@ Off-load container
-Audio Processing Manager (APM)
+Audio Processing Manager (APM)
The Audio Processing Manager (APM) is responsible for setting up and
managing the use case graphs in the ARE.
As illustrated in Figure: Audio Processing Manager, the APM provides generic public interfaces
@@ -816,28 +828,30 @@
Audio Processing Manager (APM)
-
+
+
-Audio Processing Manager
+Audio Processing Manager
The APM also handles the commands for controlling a subgraph’s state
machine:
-
+
+
-APM state machine
+APM state machine
Graph and subgraph
+Graph and subgraph
A graph is the interconnection of a list of data path modules (with input and output ports) to achieve an end-to-end use case.
A subgraph is like a graph and is used to represent a section (to @@ -602,14 +612,15 @@
Graph and subgraph
-Containers
+Containers
A container is a framework implementation that helps in executing a
group of data processing modules in the same software thread. Following figure
illustrates this concept.
-
+
+
-Containers
+Containers
@@ -628,7 +639,7 @@ Containers
-Generic container
+Generic container
Supports hardware end-point/signal triggered modules, shared memory
end‑points, encoders, decoders, packetizers, depacketizer,
@@ -672,7 +683,7 @@
Generic container
-Specialized container
+Specialized container
Mainly designed for PP modules, including complex modules like rate
matching and multi-port modules such as EC, which need syncing
@@ -724,7 +735,7 @@
Specialized container
-Off-load container
+Off-load container
Supports reduction of the processing load on the local process domain
by helping to off-load an intended module or a group of data
@@ -771,9 +782,10 @@
Off-load container
-
+
+
-Example dataflow across containers
+Example dataflow across containers
When the use case is started with the default trigger policy:
@@ -797,7 +809,7 @@ Off-load container
-Audio Processing Manager (APM)
+Audio Processing Manager (APM)
The Audio Processing Manager (APM) is responsible for setting up and
managing the use case graphs in the ARE.
As illustrated in Figure: Audio Processing Manager, the APM provides generic public interfaces
@@ -816,28 +828,30 @@
Audio Processing Manager (APM)
-
+
+
-Audio Processing Manager
+Audio Processing Manager
The APM also handles the commands for controlling a subgraph’s state
machine:
-
+
+
-APM state machine
+APM state machine
+
+
Containers
+Containers
Containers
-Generic container
+Generic container
Supports hardware end-point/signal triggered modules, shared memory
end‑points, encoders, decoders, packetizers, depacketizer,
@@ -672,7 +683,7 @@
Generic container
-Specialized container
+Specialized container
Mainly designed for PP modules, including complex modules like rate
matching and multi-port modules such as EC, which need syncing
@@ -724,7 +735,7 @@
Specialized container
-Off-load container
+Off-load container
Supports reduction of the processing load on the local process domain
by helping to off-load an intended module or a group of data
@@ -771,9 +782,10 @@
Off-load container
-
+
+
-Example dataflow across containers
+Example dataflow across containers
When the use case is started with the default trigger policy:
@@ -797,7 +809,7 @@ Off-load container
-Audio Processing Manager (APM)
+Audio Processing Manager (APM)
The Audio Processing Manager (APM) is responsible for setting up and
managing the use case graphs in the ARE.
As illustrated in Figure: Audio Processing Manager, the APM provides generic public interfaces
@@ -816,28 +828,30 @@
Audio Processing Manager (APM)
-
+
+
-Audio Processing Manager
+Audio Processing Manager
The APM also handles the commands for controlling a subgraph’s state
machine:
-
+
+
-APM state machine
+APM state machine
Supports hardware end-point/signal triggered modules, shared memory end‑points, encoders, decoders, packetizers, depacketizer, @@ -672,7 +683,7 @@
Generic container
-Specialized container
+Specialized container
Mainly designed for PP modules, including complex modules like rate
matching and multi-port modules such as EC, which need syncing
@@ -724,7 +735,7 @@
Specialized container
-Off-load container
+Off-load container
Supports reduction of the processing load on the local process domain
by helping to off-load an intended module or a group of data
@@ -771,9 +782,10 @@
Off-load container
-
+
+
-Example dataflow across containers
+Example dataflow across containers
When the use case is started with the default trigger policy:
@@ -797,7 +809,7 @@ Off-load container
-Audio Processing Manager (APM)
+Audio Processing Manager (APM)
The Audio Processing Manager (APM) is responsible for setting up and
managing the use case graphs in the ARE.
As illustrated in Figure: Audio Processing Manager, the APM provides generic public interfaces
@@ -816,28 +828,30 @@
Audio Processing Manager (APM)
-
+
+
-Audio Processing Manager
+Audio Processing Manager
The APM also handles the commands for controlling a subgraph’s state
machine:
-
+
+
-APM state machine
+APM state machine
Mainly designed for PP modules, including complex modules like rate matching and multi-port modules such as EC, which need syncing @@ -724,7 +735,7 @@
Specialized container
-Off-load container
+Off-load container
Supports reduction of the processing load on the local process domain
by helping to off-load an intended module or a group of data
@@ -771,9 +782,10 @@
Off-load container
-
+
+
-Example dataflow across containers
+Example dataflow across containers
When the use case is started with the default trigger policy:
@@ -797,7 +809,7 @@ Off-load container
-Audio Processing Manager (APM)
+Audio Processing Manager (APM)
The Audio Processing Manager (APM) is responsible for setting up and
managing the use case graphs in the ARE.
As illustrated in Figure: Audio Processing Manager, the APM provides generic public interfaces
@@ -816,28 +828,30 @@
Audio Processing Manager (APM)
-
+
+
-Audio Processing Manager
+Audio Processing Manager
The APM also handles the commands for controlling a subgraph’s state
machine:
-
+
+
-APM state machine
+APM state machine
Supports reduction of the processing load on the local process domain by helping to off-load an intended module or a group of data @@ -771,9 +782,10 @@
Off-load container
-
+
+
-Example dataflow across containers
+Example dataflow across containers
Example dataflow across containers
+Example dataflow across containers
When the use case is started with the default trigger policy:
@@ -797,7 +809,7 @@Off-load container
-Audio Processing Manager (APM)
+Audio Processing Manager (APM)
The Audio Processing Manager (APM) is responsible for setting up and
managing the use case graphs in the ARE.
As illustrated in Figure: Audio Processing Manager, the APM provides generic public interfaces
@@ -816,28 +828,30 @@
Audio Processing Manager (APM)
-
+
+
-Audio Processing Manager
+Audio Processing Manager
The APM also handles the commands for controlling a subgraph’s state
machine:
-
+
+
-APM state machine
+APM state machine
+
+
Audio Processing Manager
+Audio Processing Manager
+
+
APM state machine
+APM state machine
CLOSED
+CLOSED
The logical/non-existent graph state before OPEN and after CLOSE.
STOPPED
+STOPPED
The state after the graph is opened or transitioned from STARTED as part of STOP.
@@ -848,7 +862,7 @@ The media format is propagated through a module topology, if available.
@@ -856,7 +870,7 @@ Platform-specific resources (MIPS, bus bandwidth, and so on) are voted.
@@ -866,7 +880,7 @@ Platform-specific resources (MIPS, bus bandwidth, and so on) de-voted.
@@ -890,13 +904,14 @@
STOPPED
-PREPARED
+PREPARED
PREPARED
-STARTED
+STARTED
STARTED
-SUSPENDED
+SUSPENDED
SUSPENDED
-Audio Module Data Base (AMDB)
+Audio Module Data Base (AMDB)
The Audio Module database (AMDB) provides the database of CAPI-wrapped
modules (both static and dynamic modules) in the ARE.
-
+
+
-Audio Module Data Base
+Audio Module Data Base
The AMDB is responsible for the following operations.
@@ -915,7 +930,7 @@ Audio Module Data Base (AMDB)Audio Module Data Base
PREPARED
-STARTED
+STARTED
STARTED
-SUSPENDED
+SUSPENDED
SUSPENDED
-Audio Module Data Base (AMDB)
+Audio Module Data Base (AMDB)
The Audio Module database (AMDB) provides the database of CAPI-wrapped
modules (both static and dynamic modules) in the ARE.
-
+
+
-Audio Module Data Base
+Audio Module Data Base
The AMDB is responsible for the following operations.
@@ -915,7 +930,7 @@ Audio Module Data Base (AMDB)Audio Module Data Base
STARTED
-SUSPENDED
+SUSPENDED
SUSPENDED
-Audio Module Data Base (AMDB)
+Audio Module Data Base (AMDB)
The Audio Module database (AMDB) provides the database of CAPI-wrapped
modules (both static and dynamic modules) in the ARE.
-
+
+
-Audio Module Data Base
+Audio Module Data Base
The AMDB is responsible for the following operations.
@@ -915,7 +930,7 @@ Audio Module Data Base (AMDB)Audio Module Data Base
SUSPENDED
-Audio Module Data Base (AMDB)
+Audio Module Data Base (AMDB)
The Audio Module database (AMDB) provides the database of CAPI-wrapped
modules (both static and dynamic modules) in the ARE.
-
+
+
-Audio Module Data Base
+Audio Module Data Base
The AMDB is responsible for the following operations.
@@ -915,7 +930,7 @@ Audio Module Data Base (AMDB)Audio Module Data Base
+
+
Audio Module Data Base
+Audio Module Data Base
Built-in modules
+Built-in modules
Modules that are built with the ARE, both static and dynamic objects.
The AMDB uses the module database (module ID, entry point functions @@ -924,7 +939,7 @@
Built-in modules -
Custom modules
+Custom modules
Static Modules
+Static Modules
Static modules are loaded at boot time along with the ARE.
Dynamic Modules
+Dynamic Modules
Depending on the memory and latency tradeoffs, dynamic modules can be loaded at boot time or at a use case boundary.
Integrated Resource Monitor (IRM)
+Integrated Resource Monitor (IRM)
The Integrated Resource Monitor (IRM) provides the profiling metrics for different resources in the underlying platform.
The ARC platform displays resource metrics (MIPs, bandwidth, heap usage, and so on) for system designers.
+
+
Integrated Resource Monitor
+Integrated Resource Monitor
Platform and OS Abstraction Layer
+Platform and OS Abstraction Layer
The platform and operating system abstraction layer (POSAL) provides the necessary abstraction to the framework and makes it processor (hardware) or platform (software) agnostic.
@@ -986,20 +1002,21 @@Platform and OS Abstraction Layer
-Calibration and configuration
+Calibration and configuration
Calibration and configuration comprise the control information provided
to the module at setup and runtime to control the module’s
functionality.
-
+
+
-Calibration modes
+Calibration modes
Following are the three types of calibration interfaces exposed by the
AudioReach Engine.
+
+
Calibration modes
+Calibration modes







