Codec Engine Runtime Config

Introduction

This article describes the Codec Engine Runtime Config enhancement introduced in CE 2.26.

As a result of XDC config, a C source file and linker command file are generated, based on the configuration in the app's .cfg file. One could take these generated files, modify them as needed, and write a makefile to build the app without the XDC configuration. The C source file could even be split into multiple source files, one containing Engine configuration, one containing platform specific configuration, another containing RMAN configuration and so on. This is essentially what we have done for the Codec Engine Runtime Config feature.

We have facilitated this process by providing macros for building algorithm and engine tables, template RMAN and DMAN3 configuration files, template linker command files and platform configuration files. We have also enabled Codec Engine to query an Engine's server for remote algorithms at runtime, so the algorithm tables need only contain local algorithms.

Run-Time Configuration Source Files

1.1 C Source Files

Codec Engine supplies several source files for run-time configuration, that can be compiled and linked with the application. These files include the following:

• rtcfg.c - This file contains code that would normally be auto-generated by XDC configuration, that should never need to be modified. For example, CERuntime_init(), and stub functions for codec classes are in this source file.
• rtcfg_linux.c - This file contains Linux specific code that most likely will not need to be modified. For example, GT configuration and the Linux osal's SemMP ipc key are in this file.
• rtcfg_wince.c - Analogous to rtcfg_linux.c, but for Windows CE.
• rtcfg_dman3.c - This file contains DMAN3 configuration, if DMAN3 is used, and stubs for DMAN3 functions if DMAN3 is not used. If the app (or one of the app's algorithms) uses DMAN3, this file should be copied, modified as needed, and built into the app.
• rtcfg_rman.c - This file contains RMAN configuration. If one of the app's algorithms uses an IRES resource, this file should be copied, modified as needed, and built into the app.

Note: rtcfg.c and rtcfg_linux.c cannot be combined into a single library due to dependencies of these files: rtcfg.c contains code that depends on the Codec Engine codec class libraries, which depend on the ce library, which depends on the osal library. This dependency would require the following link order: rtcfg library, codec class libraries, ce library, osal library. On the other hand, the osal library depends on code in rtcfg_linux.c. This would require that the rtcfg library be linked in after the osal library, contrary to the previous link order requirement. Furthermore, the GT_config object is defined both in rtcfg_linux.c (and rtcfg_wince.c), and the Framework Components gt library, so linking in rtcfg_linux as a library would result in a "multiply defined symbol" link error for GT_config. The files rtcfg_dman3.c and rtcfg_rman.c could be built into a library and linked in by the app, as long as the app's local algorithms do not use DMAN3 or IRES resources. In that case the app would not link in DMAN3 or RMAN libraries (or a "multiply defined symbol" linker error will occur). Given the complications of putting these files into libraries (we would need one library per file, except that rtcfg_linux would still have to be compiled and linked in with the app because of GT_config), we felt it was simpler just to supply the source files that the app developer could modify if needed, and compile and link with. In the future, we could create an example that uses libraries, if there is demand.

These source files are located in ti/sdo/ce/utils/rtcfg. The ones that need to be modified (for example, if DMAN3 is used), can be copied to the application's source directory, and modified as needed. The app's makefile can use the vpath variable to locate the files that don't need modification. The run-time configuration examples illustrate this procedure.

Linker Command Files for Linux Builds

In addition to the source files in ti/sdo/ce/utils/rtcfg, there are linker command files for Linux. You can use these linker command files as is, or copy them to your build directory, and modify as needed. The following table lists the linker command files for available for Linux builds for several platforms, unless indicated by N/A.

Run-time Configuration Linker Command Files (Linux)
Linker Command file	Description	evm3530	evmDM365	PC
ce_debug.cmd	Debug Codec Engine libraries for apps with no DSP server
ce_release.cmd	Release Codec Engine libraries for apps with no DSP server
ce_remote_debug.cmd	Debug Codec Engine libraries for apps with DSP server		N/A	N/A
ce_remote_release.cmd	Release Codec Engine libraries for apps with DSP server		N/A	N/A
fc_debug.cmd	Debug Framework Components libraries, GT disabled
fc_release.cmd	Release Framework Components libraries, GT disabled
fc_debug_trace.cmd	Debug Framework Components libraries, GT enabled
fc_release_trace.cmd	Release Framework Components libraries, GT enabled

The makefiles for the Linux run-time configuration examples use the vpath variable to locate these linker command files, so they do not need to be copied to the application's build directory, unless they need to be modified.

WinCE Include Makefiles

There are no linker command files for Windows CE builds, since the libraries are listed in the makefiles. We have provided the following makefiles for WinCE builds, that can be included by the application's makefile:

• ce_local.mk - Codec Engine libraries for apps with no DSP server.
• ce_remote.mk - Codec Engine libraries for apps with a DSP server.
• fc_libs.mk - Framework Components libraries.

These included makefiles use variables defined in the application's makefile to reference debug or release libraries.

Runtime Configuration Examples

Codec Engine has the following run-time configuration examples:

• audio1_ires/rtcfg_* - These examples have an algorithm that uses an IRES resources, to illustrate RMAN configuration.
• speech1_copy/rtcfg_* - These are various examples with local and remote codecs.
• video1_copy/rtcfg_* - These examples have a local codec that uses DMAN3 to illustrate DMAN3 configuration.

Run-time Configuration speech1_copy Examples

The ti/sdo/ce/examples/apps/speech1_copy directory contains the original XDC configured speech1_copy example, and the following sub-directories containing run-time configuration versions of this example:

• rtcfg_DM365 - Linux example for EVM DM365 platform. There is no DSP server for this example, all algorithms are local.
• rtcfg_local_evm3530_linux - Linux example for EVM 3530 ARM. All algorithms run locally on the ARM.
• rtcfg_local_evm3530_wince - WinCE example for EVM 3530 ARM. All algorithms run locally on the ARM.
• rtcfg_PC - Linux PC example.
• rtcfg_remote_evm3530_linux - Linux example for EVM 3530. One algorithm runs locally on the ARM, another runs remotely on the DSP.
• rtcfg_remote_evm3530_wince - WinCE example for EVM 3530. One algorithm runs locally on the ARM, another runs remotely on the DSP.

These are straight-forward examples to configure, since they do not require RMAN or DMAN3. Each of these example sub-directories contains a makefile, a platform specific configuration file, and an application specific configuration file. For the Linux platforms, linker command files are also included. The run-time configuration examples use the same C source files, app.c and main_native.c, as the XDC configuration version, so we have not duplicated these files in each of the rtcfg* sub-directories.

These examples also compile and link the run-time configuration source files located in ti/sdo/ce/utils/rtcfg into the application. The makefiles use the vpath variable to locate these source files.

The Application Configuration File

Each of the run-time configuration examples contains an application configuration file, called app_config.c. This file contains configuration code that is specific to the application, such as algorithm tables and Engine configuration.

The app_config.c for rtcfg_DM365 is listed below. All algorithms in this example are local.

<syntaxhighlight lang='c'>

1. include <xdc/std.h>

1. include <ti/sdo/ce/CERuntime.h>
2. include <ti/xdais/ialg.h>

/* algorithm function tables */ extern IALG_Fxns SPHDEC1COPY_TI_ISPHDEC1COPY; extern IALG_Fxns SPHENC1COPY_TI_ISPHENC1COPY;

CE_DECLARE_TYPE(

   decoder,                       /* name */
   "ti.sdo.ce.speech1.ISPHDEC1")  /* Inheritance hierarchy */

CE_DECLARE_TYPE(

   encoder,                       /* name */
   "ti.sdo.ce.speech1.ISPHENC1")  /* Inheritance hierarchy */

CE_BEGIN_ALG_TABLE(local_table)

   CE_LOCAL_ALG(
       decoder,                      /* name used in CE_DECLARE_TYPE() */
       "mysphdec1_copy",             /* alg name */
       &SPHDEC1COPY_TI_ISPHDEC1COPY, /* IAlg functions */
       NULL,                         /* DMAN3 functions */
       NULL,                         /* IRES functions */
       0,                            /* Scratch group Id */
       Engine_USECACHEDMEM_DEFAULT)  /* Memory type: cached, non-cached etc */

   CE_LOCAL_ALG(
       encoder,                      /* name used in CE_DECLARE_TYPE() */
       "sphenc1_copy",               /* alg name */
       &SPHENC1COPY_TI_ISPHENC1COPY, /* IAlg functions */
       NULL,                         /* DMAN3 functions */
       NULL,                         /* IRES functions */
       0,                            /* Scratch group Id */
       Engine_USECACHEDMEM_DEFAULT)  /* Memory type: cached, non-cached etc */

CE_END_ALG_TABLE(local_table)

CE_BEGIN_ENGINE_TABLE(engineTab)

   CE_ENGINE(
       local_table,            /* CE_LOCAL_ALG() table name */
       "speech1_copy",         /* Engine name */
       NULL)                   /* Server name */

CE_END_ENGINE_TABLE(engineTab) </syntaxhighlight>

In app_config.c, macro calls are used to set up the Engine table of local algorithms. The first macro calls are to CE_DECLARE_TYPE(). This is to set up the inheritance hierarchies for the algorithms. For example,

<syntaxhighlight lang='c'> CE_DECLARE_TYPE(

   decoder,                       /* name */
   "ti.sdo.ce.speech1.ISPHDEC1")  /* Inheritance hierarchy */

</syntaxhighlight>

associates the inheritance hierarchy, "ti.sdo.ce.speech1.ISPHDEC1" with a symbol called decoder. The symbol name passed to CE_DECLARE_TYPE() can be any name (it is used internally to generate the name of a C-structure), and is used to associate the inheritance hierarchy with an algorithm.

The algorithm table is then declared using the CE_BEGIN_ALG_TABLE()/CE_END_ALG_TABLE() macros. The name passed to these macros, in this example, local_table, is a symbol that will be used to associate the algorithm table with an engine. This name is used internally to generate the name of a C-structure.

Inside the CE_BEGIN_ALG_TABLE()/CE_END_ALG_TABLE() macros, the local algorithms are declared using the CE_LOCAL_ALG() macro. The first argument to CE_LOCAL_ALG() is the name used in a call to the CE_DECLARE_TYPE() macro, to set the inheritance type of the algorithm. The second argument, "mysphdec1_copy" or "sphenc1_copy", is the name used in app.c for algorithm creation, in this case, the name passed to SPHDEC1_create() or SPHENC1_create().

Finally, the Engine table is declared using CE_BEGIN_ENGINE_TABLE()/CE_END_ENGINE_TABLE(). The argument passed to these macros (in this example, engineTab) is a name that is used internally to generate the name of a C-structure. The list of Engines for this table is declared with the CE_ENGINE() macro. In this example, the argument local_table, identifies the algorithm table declared previously, with the engine. The second argument to CE_ENGINE(), "speech1_copy", is the name that is used in the Engine_open() call of the application. The third argument is the name of the Engine's server, in this case, NULL, since the Engine has no server.

The remote speech1_copy examples, rtcfg_remote_evm3530_linux and rtcfg_remote_evm3530_wince, have one local algorithm and one remote algorithm. Only the local codec is added to the algorithm table, and in this case, the Engine has a server, all.x64P. Below is the Engine configuration in the app_config.c file for the remote speech1_copy examples.

Note: The server already contains an algorithm named "sphdec1_copy", so we are re-naming the local version of this algorithm to "mysphdec1_copy", to ensure that the application creates the local speech1 decoder.

<syntaxhighlight lang='c'> CE_DECLARE_TYPE(

   decoder,                       /* name */
   "ti.sdo.ce.speech1.ISPHDEC1")  /* Inheritance hierarchy */

CE_BEGIN_ALG_TABLE(local_table)

   CE_LOCAL_ALG(
       decoder,                      /* name used in CE_DECLARE_TYPE() */
       "mysphdec1_copy",             /* alg name */
       &SPHDEC1COPY_TI_ISPHDEC1COPY, /* IAlg functions */
       NULL,                         /* DMAN3 functions */
       NULL,                         /* IRES functions */
       0,                            /* Scratch group Id */
       Engine_USECACHEDMEM_DEFAULT)  /* Memory type: cached, non-cached etc */

CE_END_ALG_TABLE(local_table)

CE_BEGIN_ENGINE_TABLE(engineTab)

   CE_ENGINE(
       local_table,            /* CE_LOCAL_ALG() table name */
       "speech1_copy",         /* Engine name */
       "all.x64P")             /* Server name */

CE_END_ENGINE_TABLE(engineTab) </syntaxhighlight>

The Platform Configuration File

Each run-time configuration example also contains a platform configuration file. For the examples with only local algorithms, this file just initializes a few global variables. These files will most likely not need modification for the local case. We have named the platform configuration files for the local examples <platform>_config.c, for example DM365_config.c or evm3530_config.c.

For the remote examples, the platform configuration file initializes variables and DSP Link configuration tables for inter-processor communication. Since the DSPLink configuration tables depend on the Engine's server, we included the server's name in the platform configuration file name, for example, evm3530_config_all.c, since the server name is all.x64P.

Below is a section of the evm3530_config_all.c showing the Arm-side configuration for DSPLink.

<syntaxhighlight lang='c'> /*

*  ARM-side DSP Link memory map for server "all.x64P":
*  This table has been copied from
*      ti/sdo/ce/examples/servers/all_codecs/package/info/bin/
*              ti_platforms_evm3530/all_x64P_memtab.c
*
*/

static Global_ArmDspLinkConfigMemTableEntry memTable_all_x64P[] = {

   { "DDR2",         0x87800000, 0x87800000, 0x00600000, 1, 0 },
   { "DSPLINKMEM",   0x87E00000, 0x87E00000, 0x00100000, 1, 0 },
   { "RESET_VECTOR", 0x87F00000, 0x87F00000, 0x00001000, 1, 0 },
   { "IVAMMU",       0x5D000000, 0x5D000000, 0x00001000, 0, 0 },
   { "L4PER",        0x49000000, 0x49000000, 0x00100000, 0, 0 },
   { "IRAM",         0x107F8000, 0x5C7F8000, 0x00008000, 1, 0 },
   { "L1DSRAM",      0x10F04000, 0x5CF04000, 0x0000C000, 1, 0 },
   { "DDRALGHEAP",   0x86000000, 0x86000000, 0x01800000, 0, 0 },
   { "L4CORE",       0x48000000, 0x48000000, 0x01000000, 0, 0 },
   { "CMEM",         0x00000000, 0x00000000, 0x00000000, 0, 0 },
   { NULL, 0, 0, 0, 0, 0 }

};

/*

*  List of server names for all DspLink configuration tables.
*  Change or add your server name[s] here.
*/

String ti_sdo_ce_ipc_armDspLinkConfigServerNames[] = {

   "all.x64P",
   NULL

};

/* Arm-side DspLink configuration table for server "all.x64P": */ static Global_ArmDspLinkConfig armDspLinkConfig_all_x64P = {

   memTable_all_x64P,
   BootNoPwr

};

/* List of matching-positions-by-name DspLink configuration tables for all servers. */ Global_ArmDspLinkConfig *ti_sdo_ce_ipc_armDspLinkConfigs[] = {

   &armDspLinkConfig_all_x64P,    /* all.x64P */
   NULL

}; </syntaxhighlight>

The memory table, memTable_all_x64P, has been copied from an auto-generated file that was created when the server, all.x64P, was built. This table can either be copied from the auto-generated file, or the auto-generated file can be included in the platform configuration file. For example, we could replace the table above with

<syntaxhighlight lang='c'>

1. include <ti/sdo/ce/examples/servers/all_codecs/package/info/bin/ti_platforms_evm3530/all_x64P_memtab.c>

</syntaxhighlight>

The names of the static tables can be changed, as long as their references in the other tables are also updated. The names of the global tables must not be changed, since they are referenced by Codec Engine libraries.

Makefiles and Linker Command Files

The makefiles for the run-time configuration examples will include the xdcpaths.mak file at the root of the Codec Engine examples directory, so the tools and paths to the various installation directories only need to be set up in xdcpaths.mak.

The Linux run-time configuration examples also include linker command files containing libraries for the local algorithms. For WinCE, the makefile must explicitly list these libraries.

Run-Time Configuration audio1_ires Examples

The ti/sdo/ce/examples/apps/audio1_ires directory contains the original XDC configured audio1_ires example, and the following sub-directories containing run-time configuration versions of this example:

• rtcfg_DM365 - Linux example for EVM DM365 platform. There is no DSP server for this example, all algorithms are local.
• rtcfg_local_evm3530_linux - Linux example for EVM 3530 ARM. All algorithms run locally on the ARM.
• rtcfg_local_evm3530_wince - WinCE example for EVM 3530 ARM. All algorithms run locally on the ARM.
• rtcfg_PC - Linux PC example.

The audio1_ires example uses an algorithm that implements the IRES interface, so these examples will show run-time configuration for RMAN. Since the application and platform configuration files are similar to the speech1_copy examples, we will just describe the RMAN configuration for this example.

The default RMAN configuration file is located in ti/sdo/ce/utils/rtcfg/rtcfg_rman.c, and has RMAN disabled. To override the default RMAN configuration, each of the run-time configuration examples has its own modified copy of rtcfg_rman.c, which has changed <syntaxhighlight lang='c'>

1. define USE_RMAN 0 /* RMAN disabled */

</syntaxhighlight>

to

<syntaxhighlight lang='c'>

1. define USE_RMAN 1 /* RMAN enabled */

</syntaxhighlight>

The default RMAN configuration file already has the IRES resources needed by audio1_ires, as examples, so these do not need to be modified. In fact, setting USE_RMAN to 1 is the only modification that needs to be made, if the application registers all the IRES resources used, instead of having them auto-registered. If the resources are to be auto-registered, the RMAN_autoRegister() function in rtcfg_rman.c has to be modified to do the registration.

Run-Time Configuration video1_copy Examples

The ti/sdo/ce/examples/apps/video1_copy directory contains the original XDC configured video1_copy example, and the following sub-directories containing run-time configuration versions of this example:

• rtcfg_DM365 - Linux example for EVM DM365 platform. There is no DSP server for this example, all algorithms are local.
• rtcfg_local_evm3530_linux - Linux example for EVM 3530 ARM. All algorithms run locally on the ARM.
• rtcfg_local_evm3530_wince - WinCE example for EVM 3530 ARM. All algorithms run locally on the ARM.
• rtcfg_remote_evm3530_linux - Linux example for EVM3530. Both algorithms run remotely on the DSP.
• rtcfg_remote_evm3530_wince WinCE example for EVM3530. Both algorithms run remotely on the DSP.

The local examples use DMAN3 (cpu copy version for EVM 3530 ARM), so each local run-time configuration example contains a modified copy of the default DMAN3 configuration file, ti/sdo/ce/utils/rtcfg/rtcfg_dman3.c. The modified rtcfg_dman3.c has set

<syntaxhighlight lang='c'>

1. define USE_DMAN3 1 /* DMAN3 enabled */

</syntaxhighlight>

That is the only change, since these examples use the default DMAN3 configuration.

For the remote examples, DMAN3 is only used by the server algorithms, so no local copy of rtcfg_dman3.c is needed to enable DMAN3.

New APIs

Engine_getNumAlgs2(), Engine_getAlgInfo2()

The existing APIs <syntaxhighlight lang='c'> Engine_Error Engine_getNumAlgs(String engineName, Int *numAlgs); Engine_Error Engine_getNumAlgs(String name, Int *numAlgs); </syntaxhighlight>

only apply to algorithms that were statically configured into an engine at build time. Now that we can add remote algorithms to the engine after it has been opened, we need to be able to get algorithm information based on an Engine handle, rather than the Engine name. We have added the following new APIs to do this:

<syntaxhighlight lang='c'> Engine_Error Engine_getNumAlgs2(String name, Engine_Handle engine, Int *numAlgs); Engine_Error Engine_getAlgInfo2(String name, Engine_Handle engine, Engine_AlgInfo2 *algInfo2, Int index); </syntaxhighlight>

These new APIs take both an Engine name and an Engine handle, so that if the engine has not been opened the name can be used, and the handle set to NULL. After the engine has been opened, the handle can be passed, and NULL can be passed for the name.

The Engine_AlgInfo2 structure is identical to the Engine_AlgInfo, except the String *typeTab array field is replaced with String types. The typeTab field of Engine_AlgInfo gives the inheritance hierarchy as a null-terminated array of strings. For example, a test video decoder may have the following typeTab:

<syntaxhighlight lang='c'> static String typeTab_MP4_TII_IVIDE[] = {

   "ti.sdo.ce.video.IVIDDEC",
   "ti.sdo.ce.test.xvideo.IVIDE",
   NULL

}; </syntaxhighlight>

To simplify data obtained from algorithms in the server, we have used a single ';' separated string of types for the inheritence hierarchy of server algorithms. For the test video decoder above, the types string would be "ti.sdo.ce.video.IVIDDEC;ti.sdo.ce.test.xvideo.IVIDE". The Engine_AlgInfo2 structure is defined as:

<syntaxhighlight lang='c'> typedef struct Engine_AlgInfo2 {

   Int         algInfoSize;    /* Size of this structure. */
   String      name;           /* Name of algorithm. */
   String      types;          /* Inheritance hierarchy */
   Bool        isLocal;        /* If TRUE, run locally. */

} Engine_AlgInfo2; </syntaxhighlight>

Macros for Filling in Algorithm and Engine Tables

Codec Engine must be configured with a table of engines, each of which is configured with a table of algorithms. If the engine consists of only remote algorithms, its algorithm table can be set to NULL in app_config.c, and its algorithm table will be allocated at run-time, and filled in with data obtained from the engine's server.

To provide an alternative of having the application developer fill in tables of Engine_AlgDesc (for local algorithms) and to prevent compatibility breaks if in the future, fields are added to the Engine_AlgDesc structure, we have added macros to create algorithm and engine tables.

To use these macros, CERuntime.h must be include in the source file. Following is a description of the macros used in the run-time configuration examples.

CE_DECLARE_TYPE()

The CE_DECLARE_TYPE(name, types) macro is used to declare a type inheritance hierarchy for an algorithm. The name parameter is a symbol that will be associated with the types parameter. It will be used to generate internal variable names, so each call to CE_DECLARE_TYPE should use a unique name value. The types parameter is a ';' separated string of inheritance classes of an algorithm. For example, the viddec1_copy algorithm inherits the ti.sdo.ce.video1.IVIDDEC1 interface, so we declare its type with the line:

<syntaxhighlight lang='c'> CE_DECLARE_TYPE(viddec1_copy, "ti.sdo.ce.video1.IVIDDEC1") </syntaxhighlight>

If we had an algorithm that inherited the ti.sdo.ce.test.xvideo.IVIDE interface, which in turn inherited the ti.sdo.ce.video.IVIDDEC interface, we could declare its type as: <syntaxhighlight lang='c'> CE_DECLARE_TYPE(decoder, "ti.sdo.ce.video.IVIDDEC;ti.sdo.ce.test.xvideo.IVIDE") </syntaxhighlight>

The order of the inheritance classes in the string is not important.

CE_BEGIN_ALG_TABLE(), CE_LOCAL_ALG(), and CE_END_ALG_TABLE()

A table of local algorithms for an Engine is declared in the following manner: <syntaxhighlight lang='c'> CE_BEGIN_ALG_TABLE(algTableName)

   CE_LOCAL_ALG(name_1, ...)
   CE_LOCAL_ALG(name_2, ...)
             ...
   CE_LOCAL_ALG(name_n, ...)

CE_END_ALG_TABLE(algTableName) </syntaxhighlight>

The parameter passed to CE_BEGIN_ALG_TABLE() and CE_END_ALG_TABLE() is a symbol used internally to generate the name of a C-structure. The same symbol name must be used for both macro calls.

The CE_LOCAL_ALG() macro takes the following parameters: <syntaxhighlight lang='c'> CE_LOCAL_ALG(

       name,                 /* name used in CE_DECLARE_TYPE() */
       algName,              /* alg name */
       iAlgFxns,             /* IAlg functions */
       idma3Fxns,            /* IDMA3 functions */
       iresFxns,             /* IRES functions */
       groupId,              /* Scratch group Id */
       memType)              /* Memory type */

</syntaxhighlight>

• name - This is the same name used in a call to CE_DECLARE_TYPE(), to associate an inheritance hierarchy to the algorithm.
• String algName - This is the string name used in application code to create the algorithm, e.g., "viddec1_copy".
• IAlg_Fxns *iAlgFxns - Address of the algorithm's IAlg_Fxns table.
• Ptr idma3Fxns - Address of algorithm's IDMA3 function table, or NULL, if the algorithm does not implement IDMA3.
• Ptr iresFxns - Address of algorithm's IRES function table, or NULL, if the algorithm does not implement IRES.
• Int groupId - Resource sharing group ID.
• Engine_CachedMemType memType - Memory type for algorithm's memory requests. This can be Engine_USECACHEDMEM_NONCACHED,to request non-cached memory, Engine_USECACHEDMEM_CACHED to request cached memory, or Engine_USECACHEDMEM_DEFAULT to use the default cache setting. The default cache setting is determined by the global variable, ti_sdo_ce_alg_ALG_useCache, which is

set to TRUE or FALSE in the application configuration file.

CE_BEGIN_ENGINE_TABLE(), CE_ENGINE(), and CE_END_ENGINE_TABLE()

An Engine table is declared in the following manner:

<syntaxhighlight lang='c'> CE_BEGIN_ENGINE_TABLE(name)

   CE_ENGINE(algTab_1, ...)
   CE_ENGINE(algTab_2, ...)
        ...
   CE_ENGINE(algTab_n, ...)

CE_END_ENGINE_TABLE(name) </syntaxhighlight>

The name parameter passed to CE_BEGIN_ENGINE_TABLE() will be used to generate the name of an internal variable, and the same name must be passed to CE_END_ENGINE_TABLE(). There should only be one Engine table in the application's run-time configuration file.

The CE_ENGINE() macro takes the following parameters: <syntaxhighlight lang='c'> CE_ENGINE(

       algTableName,         /* name used in CE_BEGIN_ALG_TABLE() */
       engineName,           /* Engine name */
       serverName)           /* Server name */

</syntaxhighlight>

• algTableName - This is the same name used in a previous call to CE_BEGIN_ALG_TABLE(), to associate a table of local algorithms to the engine. If the Engine has no local algorithms, then set algTableName to NULL.
• String engineName - This is the string name of the Engine used in application code call to Engine_open(), e.g., "video1_copy".
• String serverName - This is the name of the Engine's server, if it has one, otherwise set serverName to NULL.

Note: There should be no ; placed after any of these macro calls.