Content Comparison

This 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 (awe-tc), which is used to generate configuration files. We describe each approach separately in this section.

System Configuration [R4.0] - awe_config.xml

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. Details of the XML file are found in this Section.

System Configuration [R4.2] - awe_config.yaml

We describe the basics of using the configuration files in this section. Refer to the document TBD for the full API of awe-tc.

System Booting / Early Audio

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 Gen 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 awe-tc and appears as a binary blob to the Qualcomm boot loader. The FFS will be signed using Qualcomm signing tools.

Progressive Loading

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.

Anchor
_tm17rbjtaiqb _tm17rbjtaiqb

Boot Sequence

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 module (The objectID of this SourceInt module is specified in the system configuration file.) 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.

Anchor
_g1bjk8pioe30 _g1bjk8pioe30

Parameter Control

TBD INTERACTION WITH TINYMIX.

1. Loading AWC files

2. Get Parm / Set Param

3. Etc.

Anchor
_xagn6jtsgc51 _xagn6jtsgc51

Event Handling

TBD INTERACTION WITH TINYMIX.

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:

1. Overrun occurred

2. AWE Instance has initialized

3. Audio has started pumping

4. Audio has stopped pumping

   1. Registering events with TinyMix

   2. Module events

   3. System events

Anchor
_95q4kh8ckkei _95q4kh8ckkei

Debug Log

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.

TBD detailed list of what logging information is generated

Anchor
_q44ldzcssjre _q44ldzcssjre

Subsystem Restart (SSR)

Anchor
_5njzm6ehrnzu _5njzm6ehrnzu

Low Power Sleep and Wakeup

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.

Anchor
_qt1ds4sllyr2 _qt1ds4sllyr2

CPU Overrun Reporting

Anchor
_rn1ky5codqmz _rn1ky5codqmz

Deployment

TBD Signing images and preparing boot files

Anchor
_w7ppr1wr1hps _w7ppr1wr1hps

Adding Custom Module Libraries

It is possible to add custom modules to extend the features of Audio Weaver. To do this, you need the Audio Weaver Designer Pro Edition (You will also need a Matlab license.  We recommend Matlab 2022b.) 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:

1. Install the Snapdragon tools (Hexagon SDK or Arm tools)

2. Recompile your library

3. Add your custom modules to the Audio Weaver BSP

4. 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.

Anchor
_kc24mhr01p8i _kc24mhr01p8i

Tuning Interface

Section TBD