...
Table: 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. | 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 |
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 | ||
The rest of the profiling window provides profiling information for each individual module and wire (audio buffer) in the running .awd layout:
...
While an .awd is running in Audio Weaver, the Audio Weaver Server provides real time CPU and Memory profiling of the entire layout:
...
Server Profiling on AWE Core OS Targets
In general, AWE Core OS runs in a multi threaded fashion and is not aware of which CPU the thread is running on. This means that without some extra work, the default display of CPU % cannot be trusted for multi CPU targets as the assumption is all threads run on a single CPU.
If CPU affinities are enabled on the target, server will display text percentages for each CPU that a layout is running on. The CPU percentage indicator bar will show the load for the CPU which has the highest load. Any CPUs without an associated layout will not be shown.
...
Setting and getting CPU affinities is done through the AWE Core functions awe_fwSetLayoutCoreAffinity and awe_fwGetLayoutCoreAffinity. These functions are described in the AWE Core API documentation.