Texas Instruments Codec Engine Server - Manual (Page 29)

Creating a Codec Server
Configuring a Codec Server 2-13
How you define the groupId field can affect performance or whether a
codec can be created at all. For detailed information on shared scratch
memory, see the Framework Components documentation. You may
save some time by reading the commentary for the server configuration
script in the video_copy example, which is in <CE_install_dir>/examples
/ti/sdo/ce/examples/servers/video_copy/video_copy.cfg.
What is true for sharing memory is also true for sharing DMA resources
among codecs. Again, for details, please check the Framework
Components documentation or the commentary regarding the theory and
practice of DMA configuration in the video_copy configuration example in
the script referenced above.
2.2.3.3 More About the groupId Field
Note that although both the Server.algs[] and Engine.algs[] array have an
optional groupId field, there is a distinction between the Server.algs[] and
Engine.algs[] arrays. This makes sense, if you consider that DSP-based
algorithms on a DM644x (DSP+ARM) are configured into a Server, while
the same DSP-based algorithms on a DM643x (DSP only) are configured
into an Engine.
Server.algs[].groupId
For each algorithm in the respective algs[] array, if the optional groupId is
uninitialized, the algorithm will be configured into a group with other
algorithms that have their groupId field uninitialized and run at the same
priority. If no algorithms have both of these attributes, it will be in a unique
groupId.
Exactly which groupId it will be assigned into is non-deterministic.
Therefore, it's not possible to configure scratch resources (for example,
DSKT2 scratch memory and DMAN3 DMA resources) for this non-
deterministic groupId. It's important therefore, that if the system integrator
intends for an algorithm's resources to be shared, the groupId field
should be appropriately configured.
Also, if the groupId is non-deterministically assigned, and the algorithm
requests scratch resources, these resources will be granted from (likely
non-configured) resource pools!
For example, in DSKT2-based systems, DSKT2 grants such memory
requests using the (likely non-configured)
DSKT2.DARAM_SCRATCH_SIZES[<nondeterministic-groupId>] and
DSKT2.SARAM_SCRATCH_SIZES[<nondeterministic-groupId>]
memory blocks. This can lead to strange system behavior, including
algorithms that sometimes can be created but other times fail.