Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

About This Application Note

This application note explains the different approaches for creating and implementing audio preset tunings in Audio Weaver, and assumes the reader has an intermediate or advanced understanding of the Audio Weaver framework.

What Are Presets?

In the context of audio processing and this Application Note, the term “presets” simply refers to different manufacturer audio tunings that a product may ship with, which can be dynamically loaded during operational product usage. Another commonly used synonym for audio “presets” is “modes”. Automotive and home entertainment audio systems are two common real world examples of audio preset deployment and usage.

image-20240801-033327.png
image-20240801-033348.png

Audio Weaver Preset Implementation

Before diving into the technical details of preset creation, it is important to understand the different Audio Weaver preset implementation approaches for context. Often, understanding and determining the end destination helps to efficiently plan the steps to get there.

At a high level, we’ll consider two distinct approaches for Audio Weaver tuning preset implementation: 'Internal Handling' & 'External Handling'. These two preset categorizations describe whether different audio tuning presets are implemented within a single AWD/AWB file (Internal Handling) or multiple AWD/AWB files (External Handling).

Although there are multiple tuning preset implementation techniques within those high level categorizations, the following intentionally oversimplified illustrations depict the basic functional differentiation:

image-20240801-053135.png

External Handling

When a design is exported as an .awb file for an embedded target, “loadAWBfromArray()” is called from the BSP code. This binary file contains the signal flow information, such as modules, wires, and parameters used in the design. In some cases, an entire .awb signal flow could be treated as a “preset” whereas an entirely new layout is called from the BSP. The following section will cover a method where the only thing that needs changing are the parameters and therefor a “partial” .awb can be loaded.

External Handling with “partial AWBs”

Data is split into 2 parts:

  1. AWB with structural part of the signal flow and default values (“structure AWB”)

  2. One or multiple AWB with parameter changes only, like set_value, write_float_array, etc… (“parameter AWBs”)

The BSP needs to first load the “structure AWB” to create the system, and afterwards, depending on car network signals, the corresponding “parameter AWB”

  1. Car network signals are forwarded into signal flow

  2. Mapping and naming of AWBs are done inside of signal flow

  3. Naming is based on 4 ASCII characters, packed into a single 32-bit integer value

  4. 32-bit integer is read out by BSP, BSP then loads file according to name

Parameter AWBs can be created e.g. with Matlab scripting

Keywords: awe_diary, compile command to server

AWE Tune also supports generation of parameter AWBs

<Example Matlab script>

image-20240530-172629.png

Internal Handling

Presets can also be handled internally in the signal flow

•Modules that can be used for this are for example:

  • ParamSet

  • ParamSetTableV2

  • TableSourceV2 + ArraySet

There is a specialized “MATLAB module” that parses a file to create a subsystem with ParamSetTableV2 modules that address all the parameters: “Preset Control module” BMW

Pros and Cons of Internal vs. External Handling

External Handling

  • Does not occupy additional Memory(RAM) and CPU resources

  • Only additional resources in Flash needed

  • Smaller individual AWB files

  • optional: controllable from signal flow

  • BSP involved

Internal Handling

  • No BSP involvement needed

  • Contained in signal flow

  • Higher memory and CPU resources needed

  • Bigger singular AWB file (longer loading times)

  • No labels