...
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
...
Profile Block by Block Terminology
...
Field | Definition | Unit |
Total ticks per block process available | Measurement from the end of the CPU first interrupt 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’.
Both of these units should nearly match, however be aware that if there are CPU overflows (>100% processing load), the ‘Measured’ metric may will be increased/doubled because doubled. In this scenario, since the audio pump was 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 | 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:
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:
...