...
Audio Reach | Audio Weaver |
Developed for power constrained mobile products. Single use case. | Developed for high-performance automotive audio. Multiple concurrent use cases. |
Variable processing load. | Constant / deterministic real-time load |
Must keep cores loaded < 70% | Can load cores to 90% |
Separate AMS framework needed for low latency support. End-to-end digital latency of 3 x block size. | Native low-latency support. End-to-end digital latency of 2 x block size. |
TDM ports aligned within 12 samples | TDM ports aligned within 1 sample |
SysMon does not provide actionable information to fully load the system. | Easy to understand profiling. Per module, per thread, and per core. Show average and peak CPU load. |
Only supports Hexagon DSPs; no Arm. | Supports all cores including Arm. |
QXDM is a poor fit for real-time debugging. | Includes integrated visual debugging tools and legacy QXDM. |
Numerous side effects. Many features can only be supported by Qualcomm. | Architecture is fully documented and information is publicly available. |
| Anchor | ||
|---|---|---|
|
...
The section is aimed at the software engineer that needs to integrate Audio Weaver into the rest of their automotive software base. It focuses on system initialization and run-time control. All audio features - including I/O - are configured via the Audio Weaver signal flow.
Release R4.0 provides basic tooling based on Python scripts. Release R4.1 improves upon this with a separate tool, called Audio Weaver Target Configurator (AWETC), which is used to generate configuration files. We describe each approach separately in this section.
...
In this release, the configuration information needed to set up the BSP is described by an XML file. This file is converted to a binary representation which is more easily parsed at run-time. This conversion uses Python files. A fully annotated XML file is shown in Section TBD; we provide more details here.
...
Controls the amount of logging information generated by Audio Weaver. This is set per core and the following 3 values are supported.
0 - Log only critical errors.
1 - Also include non-fatal warnings
2 - Also include informational messages
When a higher value is selected, all messages from the lower log levels are also included. For example, if you set log_level = 2, then you will see critical errors and non-fatal warnings in additional informational messages.
...
Number of audio processing threads that will be provided. This number appears on the Server window when you connect to the target.
If you exceed this number, then you will get a build error in Designer. On the Hexagon, the audio processing threads are scheduled via the QuRT RTOS and do not necessarily map to hardware threads. It can also be useful to have the number of audio processing threads exceed the number of hardware threads because some audio processing threads may not be fully loaded.
On the Arm, audio processing threads are also mapped to software threads via the operating system.
...
Specifies the priority of the main audio interrupt. This is the highest priority interrupt on the core and should have the highest priority. On the Hexagon, the lower the number the higher the priority. We recommend setting this to 50. On the Arm, the higher the number the higher the priority. We recommend setting this to 63.
...
Specifies the priorities of the audio processing threads. These are the threads that do the actual work. They should be in decreasing order of priority.
If your system is experiencing CPU overruns, there are 3 possible ways to correct this.
Adjust the thread priorities. Something else is running in the system and pre-empting audio processing.
Load balance your audio threads. Try to minimize the peak load of any thread.
Reduce the amount of audio processing. You’ll need to redesign your signal flow, leverage multichannel signals, or in some cases, change your block size.
...
Total number of audio processing cores available. This number is set based on the specific variant of the Snapdragon processor used. There are variants with 1, 2, or 3 cores. Including the Arm leads to 2, 3, or 4 cores.
...
This section has core specific information and there are similar sections for GPDSP0, GPDSP1, and the Arm.
<coreID> - unique integer identifier for the core. This maps to the “InstanceID” used in Audio Weaver.
<fastheapA>, <fastheapB>, <slowheap> - specifies the number of 32-bit words that should be allocated for each heap. Size this based on the complexity of your audio design. There is no harm in oversizing this.
<cpuclock> - initial core clock setting, in kHz. This value is used to set the clock speed of the Hexagon DSPs. It does not affect the Arm clock speed. In all cases, this information is used to convert the measured percent usage to MHz. If the MHz values in your profiles do not look correct, then these values could be off.
...
Specifies the size of the system wide shared heap, in words.
...
There are also settings in the XML file for <block_size>, <sample_rate>, <in_channel>, <out_channel>. These values are used to populate the targetInfo structure used by the Server but they are not actually used by the BSP to configure the system. They are only used for legal information provided by the Server to the Designer GUI.
...
We describe the basics of using the configuration files in this section. Refer to the document TBD for the full API of AWETC.
...
This section describes how the Snapdragon audio subsystem is initialized during the boot process. There is some complexity because part of the audio subsystem is initialized early during the boot sequence in order to support OEM early audio requirements. Then, when the rest of the system is running (i.e., the high-level OS), then the rest of the audio system is initialized. Thus, there is an “early boot” and a “late boot” phase for the audio subsystem.
There is different partitioning between the Gen4 and the Gen5 hardware. On the 8255, all of the Hexagon DSPs are part of the early boot set and only the Arm is in the late boot set. On Ge 5, only DSP0 is part of the early boot set and DSP1, DSP2, and the Arm are part of the late boot set.
Audio Weaver also has access to 10 MB of early boot data which is stored in UEFI flash memory. Multiple files are stored in a structure we call the Flash File System (or FFS). The FFS is a simple file system and we use it to hold a variety of different files:
The system configuration file
AWB files to initialize the signal flow
Preset AWB files for calibration data (e.g., setting chime gains or chime locations)
WAV data to customize chimes and alerts
The FFS is generated using AWETC and appears as a binary blob to the Qualcomm boot loader.
...
The split boot phases are enabled by the Progressive Loading feature of Audio Weaver. The audio engineer starts by creating a multicore signal flow using Audio Weaver Designer that implements all use cases. Next, they generate target files for the system and select the option to “Split multi-layout”. This generates a separate AWB file per audio processor. On the 8255, you would end up with: adsp.awb, gpdsp0.awb, gpdsp2.awb, and arm.awb.
The AWB files are then loaded progressively (or sequentially) at boot time. First adsp.awb would load, and if the ADSP signal flow contains enough modules to generate sound by itself (TDM ports, WAV players, etc. ), then the system can generate sound at this point. Next, gpdsp0.awb would load and add the modules running on GPDSP0. During this time, the ADSP continues to run uninterrupted. Finally, gpdsp1.awb would be loaded on GPDSP1 and the signal flow extended. Progressive loading relies on special logic within the ChangeThread module which enables the module to execute even if its “partner” core is not yet ready.
The same process applies to the late boot Arm core. arm.awb would be loaded and the signal flow extended.
The system configuration file contains information about which AWB files to load and which core they are loaded on. This allows you to fine tune the boot process and arrange the order of loading signal flows and presets.
...
The early boot process is illustrated below. The DSP executable images are loaded from flash memory and the DSPs start executing. All of the DSPs access the config.bin information from flash memory and start their initialization. One of the DSPs is identified as the Primary Audio Core (PAC) in config.bin and is responsible for coordinating the boot process. In the example below the ADSP is the PAC, and its boot sequence is specified in config.bin. First, adsp.awb is loaded and when done, it is possible for the system to generate early audio. After the ADSP is finished loading its AWB, it signals the next core (in this example GPDSP0), and this core loads its AWB next. This continues until all cores in the early set are loaded.
During the early audio phase, Audio Weaver is signaled by the Qualcomm Safety Application Intermediate Layer (SAIL) when chimes are to be played. SAIL will use a TBD word payload which is written directly into a dedicated Audio Weaver SourceInt module2. This module can then be used to arbitrarily trigger and control sound players inside the Audio Weaver signal flow. The details are left up to the signal flow designer.
...
NEED HELP FROM QUALCOMM TO FILL OUT THIS SECTION. ESPECIALLY WHAT THE INTERACTION WITH TINYMIX WILL BE.
Loading AWC files
Get Parm / Set Param
Etc.
...
NEED HELP FROM QUALCOMM TO FILL OUT THIS SECTION. ESPECIALLY WHAT THE INTERACTION WITH TINYMIX WILL BE.
Events can be generated two different ways: (1) Modules can generate “Module Events”, and (2) the BSP can generate “System Events”. Both types of events use the same callback handling. Events include a category (module or system), an eventType, and a payload.
BSP System Events are predefined and include:
Overrun occurred
AWE Instance has initialized
Audio has started pumping
Audio has stopped pumping
Registering events with TinyMix
Module events
System events
...
The audio processing subsystem logs status and debug information directly to the QXDM log. Information originates from these areas:
Audio Weaver BSP code (e.g., peripheral initialization, device errors, etc.)
AWECore library (e.g., out of memory, module errors)
The QXDM logging is only available after the HLOS has booted. During early audio, the log information will be written to shared memory and it is available using TBD.
Do we need to make a detailed list of what logging information is generated?
...
The audio subsystem can be put into a low power mode by sending the TBD command via TinyMix. In this state, all audio interrupts are disabled (no pumping occurs), and the internal module state variables are reset to default values. (This prevents pops and clicks when the system restarts.) All internal parameters - such as volume or tone controls - are unchanged.
Later on, to resume audio processing the TBD command is sent. This restarts DMA and processing of audio resumes.
...
Signing images and preparing boot files
...
It is possible to add custom modules to extend the features of Audio Weaver. To do this, you need the Audio Weaver Designer Pro Edition3 and the Custom Module SDK. We recommend developing and debugging your modules on the PC. Then, you’ll need to follow these steps to deploy on Snapdragon:
Install the Snapdragon tools (Hexagon SDK or Arm tools)
Recompile your library
Add your custom modules to the Audio Weaver BSP
Compile and link the Audio Weaver BSP to generate new images
The overall process is described separately in the document Deploying Custom Modules to Audio Lite_V1.0.0.pdf.
...
Is this always available or does it have to be launched via the command line? (I assume we don’t want this running in the production environment.)
| Anchor | |||
|---|---|---|---|
|
...
Serial port I/O is accomplished by two modules: SnapdragonTDMSource and SnapdragonTDMSink. These modules appear in the module browser as shown below.
You can add multiple TDM Serial Port modules to your signal flow and interface to multiple hardware devices. Release 4.0 has the following restrictions:
...
numChannels, blockSize, and sampleRate - specify the properties of the TDM port. If this is an input module, then these values will also specify the properties of the output wire. If this is an output port, then the wire properties at the input must match these values. The sampleRate value is taken from a droplist:
clockingMode - specifies the clocking properties that was described above:
...
The module inspector is shown below.
This provides further control of the module
...
The module has an output pin with 1 channel and a block size of 1 (it is a control signal). The output wire will hold a single floating-point value. The module’s inspector allows you to choose which of 12 system variables to output:
This module returns internal information from the AWECore library and the layout (thread) that the module is running in. The following items can be selected:
...
The board shown below is the “Rev D” version. There are 4 smaller jumper switches and they need to be set as shown:
1 Unless, of course, you want to write your own custom modules that execute on the Hexagon.
...