Creating a Codec Server

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.3More 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.

Configuring a Codec Server

2-13

Page 29
Image 29
Texas Instruments Codec Engine Server manual More About the groupId Field, Server.algs.groupId

Codec Engine Server specifications

Texas Instruments Codec Engine Server (CES) is a powerful software framework designed to handle audio and video processing on embedded systems. It serves as a bridge between high-level application programming and low-level codec implementations, simplifying the development of multimedia applications. The Codec Engine's primary focus is on optimizing media codecs for applications such as telecommunications, video conferencing, multimedia playback, and streaming services.

One of the standout features of the CES is its ability to support multiple codecs simultaneously, allowing developers to efficiently decode and encode various media formats in real time. This flexibility is crucial for applications that demand high-quality audio and video processing without compromising performance. Furthermore, the CES architecture promotes modular design, enabling developers to swap in and out different codec implementations based on specific project requirements.

The CES leverages advanced technologies including simultaneous multithreading, which maximizes the processing power of multi-core processors. With this capability, developers can allocate threads efficiently across multiple cores, tackling demanding tasks without latency. Additionally, the framework supports dynamic codec allocation, meaning that resources can be managed and adjusted on-the-fly as needed, ensuring optimal performance in varying conditions.

Another significant characteristic of the CES is its compatibility with various Texas Instruments DSP (Digital Signal Processor) platforms. This ensures that developers can take advantage of the specialized capabilities of TI's hardware, including their power management features and high-performance processing capabilities. The integration of hardware and software within the CES architecture allows for optimized resource utilization, leading to energy-efficient applications.

The development process is further streamlined through the use of a comprehensive API (Application Programming Interface) that provides access to codec functionalities while abstracting the complexities of underlying hardware. This allows developers to focus on building high-level features without getting bogged down in low-level programming details.

In conclusion, Texas Instruments Codec Engine Server stands out as a robust solution for developers aiming to create high-performance media applications. Its support for multiple codecs, efficient resource management, and compatibility with TI DSP platforms make it an indispensable tool in the multimedia processing space. By facilitating seamless interaction between hardware and software, CES empowers developers to deliver richer multimedia experiences in their applications.