Dynamic metadata creation is similiar to static, but accepts arguments for the creation process, hence the dynamic. The object receives all configuration data being considered (in most cases this would be by GTT) and writes relevant information to the member m_DynamicMetadata in response.
virtual void createDynamicMetadata(ioObjectConfigInput& configIn, ioObjectConfigOutput& configOut);
dynamicMetadata getDynamicMetadata() { return m_DynamicMetadata; }
Create Dynamic Metadata
createDynamicMetadata is called after a successful call to getObjectIo. It can further restrict values in the ioObjectConfigOutput struct. All required information is passed in with configIn.
- audioIn & audioOut – instances of type metaDataDescription which label and set restrictions for inputs and outputs. Label need not be specified if a generic label will suffice. (eg: Input 1) If not, supply a label for each input and output.
- controlIn & controlOut – are vectors of type metaDataControlDescription which label and specify value ranges for each control input. The number of controls is dictated by other. parameters, so we don’t have to bound the min and max. Note: Min and Max are not enforced, they are only informative to the user.
- estMemory – Estimated memory consumption for the current configuration (in bytes).
- estMIPS – estimated consumption of processor (in millions of cycles per second, so not really MIPS).
Get Dynamic Metadata
This method simply returns a copy of m_DynamicMetadata. Note that it is not virtual.
Description of Structures
These structures are used by the tool during signal design. The input configuration struct holds all *attempted* parameters, the output struct is used to constrain audio inputs and outputs and report the correct number of control inputs and outputs.
In-Place Computation
This feature allows Audio Objects to give the GTT the ability to operate in in-place computation mode. In this mode, the audio object uses the same buffers for input and output. This option has been moved from static metadata to dynamic metadata to support a kernel-based decision. This allows the AO developer to decide, based on the target architecture, whether or not it is beneficial to run the calc function in-place.
GTT analyses the signal flow and calculates the amount of buffers required for the given signal flow. If isInplaceComputationSupported is set by the audio object developer, GTT tells the framework to allocate only input buffers only.
The isInplaceComputationSupported flag can be checked in the the audio object’s dynamic metadata.
For example, Gain configured for 6 channels :
- If isInplaceComputationSupported is not set, it will use a total of 12 buffers.
- If isInplaceComputationSupported is set, it will use a total of 6 buffers.
In-place computation feature has the following benefits:
- reduces flash size.
- reduces number of IO streams which improves the memory performance on embedded.
Current Limitation or Additional conditions
An Audio Object Marked is considered for in-place has to satisfy following three conditions:
- Audio Object should have dynamic metadata flag isInplaceComputationSupported set to true for the selected core type.
- Audio Object should have equal number of input and output pins.
- All audio pins should be connected.