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.

Open

Home Entertainment Audio “Presets”

Open

Automotive Audio System “Presets”

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 can help 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:

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 therefore a “partial” .awb can be loaded.

External Handling with “preset AWBs”

Data is split into 2 parts:

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

   1. A structure AWB contains the entire signal flow as a target-specific binary file and can be generated from Designer in the Tools -> Generate Target Files window, or compiled from an AWS. It can either be generated at runtime behind the scenes when tuning on target, or be loaded at startup by the BSP. The latter is detailed in this App Note: (8.D.2.5) Control Interface Usage and Debugging

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

   1. This parameter or preset AWB can contain just the changes a user wishes to make to a design that is already running. Similar to a parameter AWS but in binary format, it uses tuning commands to overwrite parameters while a design is running. This could be used to enable/disable parts of a design, change user modes, or switching EQ presets for example.

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 AWB’s

Generating a preset AWB

Follow these steps to create a “preset” or “parameter” AWB.

1. With a single design functioning as our “structure” AWB, we’ll want to track changes made to parameters which make up the preset changes that take place when executed. For this example, changes to the design will take place while running the design in Designer Pro. Open Designer using matlab with the “awe_designer” command, then open and run the design.

2. Use the awe_diary matlab script to begin recording any changes made to a design into an .aws (Audio Weaver Script) file. This example uses the name “preset.aws”

   awe_diary('on', 'preset.aws');

3. In the design, make changes to the parameters you wish to change. In this example the design “HW_Button_Mute.awd is used from the Control Interface and Debugging app note here: (8.D.2.5) Control Interface Usage and Debugging and the change made was in the PeriodicFuncGen1 module on the “freq” parameter (from 1000 to 1500Hz):

4. When finished making changes for this preset, in matlab run the command:

5. A new preset.aws file will be generated in the current matlab path and shows the following:

6. (Optional, or proceed to step 8) Before converting this preset.aws to an .awb we can run a simple test that the preset script works when executed. Start by running the design, in this case with freq set back to 1000. This could also be run Natively or Embedded using the structure .aws from the Server window by going to File → Execute Script:

7. With the design running, in the Server window go to File → Execute script again, but this time select preset.aws. The design should continue to run, with the only change being the frequency parameter.

8. With the preset.aws confirmed to be working, we can convert to an .awb file by going to File → Compile Script in the Server window:

9. Select the preset.aws source file and destination for an .awb in the AWE Script Compiler Window:

10. This .awb can also be executed from Server window in the same manner as the .aws file.

11. To load a preset in standalone mode with a BSP that has flash file system support, users can use the flash manager to store and execute structure and preset AWBs. Documentation on setting up a flash file system can be found here: AWE Core 8.D.9 Documentation: AWE Core 8 Integration Guide

Internal Handling

Presets can also be handled internally in the signal flow

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

• ParamSet

  • Example:

• ParamSetTableV2

  • Example:

• TableSourceV2 + ArraySet

  • Example:

NOTE: Functionality in Param Set Table V2 can also be achieved with combining the Array Set and Table Source V2 modules for multi-dim tables or Param Set modules for scalar variables. But Param Set Table V2 adds more convenience, e.g. it supports writing into scalar values (not arrays only), Array Set by itself does not support "OnChangeSet" behavior, hence fewer number of modules in total will be required.

Pros and Cons of Internal vs. External Handling