Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • Total ticks per block process available (calculated and measured)

  • Average ticks per block

  • Instantaneous ticks per block

  • Peak ticks per block

  • Total memory usage of the system

  • Shared heap memory for multi-instance architectures

...

image-20240430-034601.pngImage Added

Profile Block by Block Terminology

...

Field

Definition

Unit

Total ticks per block process available

Measurement from the end of the CPU first interrupt, to the end of the next CPU interrupt (i.e., how many clock cycles have elapsed on the processor). This is a rough indication of how many clock cycles are available for processing. (You will not be able to utilize 100% of cycles because the audio interrupt handle requires some processing.) 

This is an especially important number to check when you are bringing up new hardware. The value shown here should be close to:

(Processor Speed) x (Block Size of Processing) / (Sample Rate)

If this doesn’t match, then there could be a mismatch in your processor speed, the audio sample rate, or the underlying “fundamental block size” of your implementation.

Lastly, there are two separate line items for ‘Total ticks per block process available’.

  • Calculated: Manually calculated based on the processor clock speed and the block size and sample rate of the layout

  • Measured: Processor clock ticks measured between blocks, based on the calling rate of the audio pump

Both of these units should nearly match, however be aware that if there are CPU overflows (>100% processing load), the ‘Measured’ metric will be doubled. In this scenario, since the audio pump is not completed during the current block of processing, the measured metric would include the next block as well.

CPU clock cycles

Average ticks per block used

Average of CPU clock cycles per block of audio data (10x)

CPU clock cycles

Instantaneous ticks per block used

CPU clock cycles required to process the last block of audio. This is the instantaneous measurement without smoothing. This number will change every time you profile.

CPU clock cycles

Peak ticks per block used

Peak instantaneous CPU clock cycles consumed when processing a block of audio data. This is a “sticky measurement” and shows the peak value since system startup. If you reprofile, then it will reset this value.

CPU clock cycles

Fast Heap

Memory usage from the memory allocated in the Fast Heap

Words

Fast Heap B

Memory usage from the memory allocated in the Fast Heap B

Words

Slow Heap

Memory usage from the memory allocated in the Slow Heap

Words

Total Memory

Fast Heap + Fast Heap B + Slow Heap

Words

Shared Heap

Memory usage from the allocated Shared Heap

Words

Heaps

At initialization time, memory to be used by the AWE Core instance for signal processing is allocated. The AWE Core refers to this memory as the heap. By default, AWE Core supports three heaps for which the BSP is responsible for allocating storage. Most commonly, heaps are allocated statically as large arrays. The heaps are:

  • FASTA: storage accessible using the least time

  • FASTB: a secondary bank of fast storage. Useful for memory that can be concurrently accessed with FASTA heaps

  • SLOW: storage usually external and so more slowly accessed

  • SHARED: Storage shared by and accessible to multiple Audio Weaver instances, used for multi-instance or IPC communication

To calculate Memory in MB: ((Total Heap Memory) * 4)/1000000

...

As mentioned earlier in this application note, Audio Weaver also features Manual Profiling, which collects the same exact profiling information as the real-time block by block profiling but allows a user to select a specific number of audio frames to process.  This may be useful for .awd layouts that cannot be run in real-time or for obtaining profiling information on targets that haven’t been configured for real-time audio yetin a different manner. Rather than profiling the runtime input audio stream, during manual profiling, real-time processing is halted on the target and all layouts present in the AWD/AWJ signal flow are processed one at a time through tuning commands (pump_layout), for the user specified amount of audio frames. The yielded profiling results may be preferred in some cases, as this decouples discrete layout processing (and thus layout thread priority) from real-time audio device interrupts. This allows for accurate profiling even in cases when the target is not configured for real-time audio, or if a layout is unable to finish executing in the allotted clock cycles (calculated total ticks per block process available).

To Manual Profile an .awd layout, navigate to ‘Tools > Profile Running Layout > Manual Profile Layout’ in the Audio Weaver Designer toolbar while in Tuning Mode:

...

For multi-instance architectures, every Audio Weaver profiling utility enables users to export either profiling data for all instances or individual profiling data for a selected Audio Weaver instance:

...

image-20240429-145818.pngImage Added

image-20240429-145854.pngImage Added

For block by block and manual profiling of multi-instance architectures, if profiling data for all instances are selected for export, Audio Weaver will generate one aggregate profiling CSV file and individual CSV files for each Audio Weaver instance in the system:

...