API functions using Codec Engine (ii)

This article is translated from TI's Handbook, the Handbook is a study of gpp+dsp development of the Golden Code document, I hope that the introduction of the help, there is an inappropriate understanding of the hope please enlighten.
Codec Engine Application Developer User ' s Guide.pdf (literature number:sprue67d)
"Codec Engine Application Development Manual" http://blog.csdn.net/dyzok88/article/details/42154487
Chapter One Codec Engine Overview http://blog.csdn.net/dyzok88/article/details/42214813
Chapter II Installation and setup of Codec Engine http://blog.csdn.net/dyzok88/article/details/42278109
Chapter Three uses CODEC Engine's sample application http://blog.csdn.net/dyzok88/article/details/42302793

<span style= "font-family:arial, Helvetica, Sans-serif;color: #ff0000;" ><span style= "Background-color:rgb (255, 255, 255); >//Body </span></span>

<span style= "font-family:arial, Helvetica, Sans-serif;color: #ff0000;" ><span style= "Background-color:rgb (255, 255, 255); ></span></span>

4.2.1 Codec Engine Configuration Code

Applications that use Codec Engine should include the following header files, which are relative to the package path, including Ce_install_dir and Xdc_root.

<span style= "Font-size:14px;color: #ff0000;" > #include <xdc/std.h> #include <ti/sdo/ce/Engine.h> #include <ti/sdo/ce/ceruntime.h></span >

In addition, the application must include header files used by any VISA module, such as:

<span style= "Font-size:14px;color: #ff0000;" > #include <ti/sdo/ce/audio/auddec.h></span>

Note that the path to the header file exactly corresponds to the path of the package shown in table 4-2, Codec Engine Modules.

Table 4–2 Codec Engine Modules

All applications that use Codec Engine must run Ceruntime_init. Typically, this is run from the main () function of the application.

In addition, when building a GPP+DSP application that uses Codec Engine, you must load the dependent modules Dsp/bios Link and CMEM (continuous memory allocator). Check the examples/apps/system_files/davinci/loadmodules.sh file to see how this is implemented. See the build_instructions.html file for details.

4.2.2 Open an engine

When you open an engine, you can specify the name of the engine you want to open. For example:

<span style= "Font-size:14px;color: #ff0000;" >static String enginename = "Auddec"; Engine_handle CE; Engine_error errorcode;ce = Engine_open (Enginename, NULL, &errorcode);</span>

Note: Note that the engine handle (handles) is not thread protected. Each thread that uses an instance of the engine should perform its own engine_open () function call and use its own engine handle. This protects every instance of the engine from being accessed by other threads in a multithreaded environment.

The engine is configured by your engine engineer, and the engine engineer decides which algorithms to configure and compile to each engine. See chapter 5th, "Integrating an engine" to understand the information that an engine engineer needs to build such an engine.

For example, in a dual-CPU system, such as a dm644x device, the algorithm can be run locally (in GPP) or "remote" (in DSP). For the remote algorithm, the transparent engine uses the "DSP Server" and the DSP Link Channel to run the high-speed algorithm. Here, the first invocation of Engine_open () causes the following basic operations:

1. Turn on the DSP (if the Ti.sdo.ce.osal.Global configuration file supports configurable)

2. Initialize the DSP and channel calls to the Link API function: Proc_setup (), Proc_attach (), Pool_open (), Proc_load (), Proc_start (), and Msgq_transportopen ()。

3. Start the initial handshake from the GPP side to the remote allocator on the DSP.

The Engine_open () function allows you to pass the ENGINE_ATTRS structure to the engine. This type is defined in Engine.h, and the header file is included by the application. Currently, this structure allows you to specify the ID of the process that runs the DSP server for the engine. If you have more than one processor, you only need to provide the same service and the service ID you are currently using, and the default procid is 0.

<span style= "Font-size:14px;color: #ff0000;" >typedef struct Engine_attrs {String procid;} Engine_attrs;</span>

If the Engine_handle returned by Engine_open () is NULL, the engine cannot be opened. If the error code parameter is non-null, the Engine_error value is set to one of the following values:

1. Engine_eok. Open successfully.
2. Engine_eexist. The engine name does not exist.
3. Engine_enomem. Unable to allocate memory.
4. Engine_edspload. The DSP could not be loaded.
5. Engine_enocomm. Unable to establish communication link with DSP.
6. Engine_enoserver. The server on the DSP could not be found.
7. Engine_ecomalloc. Cannot allocate a communication buffer.

Your application can handle this error. For example:

<span style= "Font-size:14px;color: #ff0000;"             >ce = Engine_open (enginename, NULL, &errorcode), if (CE = = null) {printf ("error:could not open Engine \"%s\ "; Error code%d.\n ", Enginename, ErrorCode);} </span>

4.2.3 shut down an engine

To close an engine instance and release the memory it uses, your application should call Engine_close (). For example:

<span style= "Font-size:14px;color: #ff0000;" >engine_close (CE);</span>

You should do so after you have removed any algorithm instances that the engine created and freed all buffers or other memory-related algorithm instances.

For example, the dm644x-based example described in the previous section: Executing a remote algorithm on a DSP, the last Call to Engine_close () causes the following basic operations:

1. Call the Api:msgq_transportclose (), Proc_stop (), Pool_close (), Proc_detach (), and Proc_destroy () that require a "finalize" DSP and a transport link.

2. Turn off the DSP (if the Ti.sdo.ce.osal.Global configuration file supports configurable).

4.2.4 getting memory and CPU information from the engine

You can use the Engine_getusedmem () function to get information about using an engine instance memory. The value returned is the total amount of memory that can be allocated from the currently available heap (in MAUs). Note that this value can vary between calls, depending on the DSP server activity. For example, when the first algorithm is instantiated on a DSP server, the data structure can be allocated in addition to the individual algorithm instances that are required. These additional memory allocations are assigned to the "first requested request", even if the algorithm is deleted, maintaining the global state of the assignment,

In addition to Engine_getusedmem (), server API functions can also be used to obtain memory usage information about individual heaps on the DSP, as described in section 4.4 for these functions.

You can use the Engine_getcpuload () function to obtain the CPU utilization of the DSP server, from 0 to 100 integers. This value shows that the DSP server was measured for a period of approximately 1 seconds, with a elapsed percentage.

4.2.5 Gets the information of the algorithm configuration in an engine

An application can determine the number of algorithms that are configured into the engine and the characteristics of the algorithm, such as the name of the algorithm, local or remote algorithms.

The following API functions can be used to obtain the number of algorithms:

<span style= "Font-size:14px;color: #ff0000;" >engine_error Engine_getnumalgs (String name, Int *numalgs) </span>

The parameter "name", which is the name of the engine, returns the following values:

1. Engine_eok. Success. In this case, *NUMALGS returns the number of algorithms that are configured into the engine.

2. Engine_eexist. Engine without a given name.

Once the number of algorithms in the engine is known, the application can call the function engine_getalginfo () repeatedly to get information about each algorithm. This information is put into the engine_alginfo structure, which is defined as follows:

<span style= "Font-size:14px;color: #ff0000;"    >typedef struct Engine_alginfo {Int alginfosize;           /* Size of this structure */String name;       /* Name of Algorithm */String *typetab;        /* Inheritance Hierarchy */Bool isLocal; /* If TRUE, run locally */} engine_alginfo;</span>

The first member of the Engine_alginfo struct, "alginfosize", must be set by the application to the size of the structure; it will be used to support future enhancements to the structure. The following example shows the use of these API functions (no error checking for readability):

<span style= "Font-size:14px;color: #ff0000;" >int Numalgs, I; Engine_alginfo Alginfo; Engine_error Err;err = Engine_getnumalgs ("Audio_copy", &numalgs); for (i = 0; i < Numalgs; i++) {err = En    Gine_getalginfo (name, &alginfo, i); printf ("alg[%d]: Name =%s Typetab =%s local =%d\n", I, Alginfo.name, * (Alginfo.typetab), alginfo.islo-cal);} </span>

The output may resemble the following:

<span style= "Font-size:14px;color: #ff0000;" >ALG[0]: name = auddec_copy Typetab = Ti.sdo.ce.audio.IAUDDEC local = 0alg[1]: name = audenc_copy Typetab = Ti.sdo.ce.a Udio. Iaudenc local = 0</span>

struct member Typetab, which is actually a NULL-terminated array of strings reserved for the inheritance hierarchy.

The return value of Engine_getalginfo () is as follows:

1. Engine_eok. Success.
2. Engine_eexist. Engine without a given name.
3. Engine_einval. The value of the Engine_alginfo object Alginfosize passed to this function does not match the size of the Engine_alginfo object in the codec engine library.
4. Engine_enotfound. The index of the algorithm is out of range.

API functions using Codec Engine (ii)