DSP

使用 Codec Engine 的 API 函数(六)

2019-07-13 20:59发布

 本文翻译自TI的手册,该手册是学习GPP+DSP开发的金典文档,希望对各位入门有所帮助,有理解不当之处望请赐教。
 Codec Engine Application Developer User's Guide.pdf (Literature Number: SPRUE67D)
《Codec Engine 应用开发使用手册》              http://blog.csdn.net/dyzok88/article/details/42154487
《第一章 Codec Engine 概要》                   http://blog.csdn.net/dyzok88/article/details/42214813
《第二章 Codec Engine 安装和设置》             http://blog.csdn.net/dyzok88/article/details/42278109 《第三章 使用 Codec Engine 的示例应用程序》    http://blog.csdn.net/dyzok88/article/details/42302793
《第四章 使用 Codec Engine 的 API 函数 (一)》http://blog.csdn.net/dyzok88/article/details/42323123
《第四章 使用 Codec Engine 的 API 函数 (二)》http://blog.csdn.net/dyzok88/article/details/42324061
《第四章 使用 Codec Engine 的 API 函数 (三)》http://blog.csdn.net/dyzok88/article/details/42344661
《第四章 使用 Codec Engine 的 API 函数 (四)》http://blog.csdn.net/dyzok88/article/details/42353141 《第四章 使用 Codec Engine 的 API 函数 (五)》http://blog.csdn.net/dyzok88/article/details/42374715
// 正文

4.6 发生什么 DSP 实时问题?

从 GPP 的角度处理所有多线程和实时问题是 GPP 应用程序的责任。例如,在基于Linux的系统上,这可能涉及调度较高频率,在相比长持续时间的处理(如视频)更高的优先级上的短持续时间的处理(如音频)。 DSP Server 被 Codec Engine 远程算法透明使用,用来处理 DSP 的多线程和重入问题。对于 DM644x 的平台,DSP 被当作一个黑盒子对待,DSP 线程问题是由编解码器集成服务器管理。 然而,仍然有一些重要的考虑因素。

4.6.1 事务延迟

运行来自 GPP 的 DSP 算法时,考虑事务等待时间是很重要的。例如,DM644x 根据所需的往返时间来安排的 DSP 算法,GPP 限制tps(transactions-per-second)大约为7000。也就是说,应用程序可以使用 Codec Engine 运行或控制算法高达每秒7000次。 当考虑每秒 30 到 50 典型的帧速率时,这可能看起来像有大量的空间。但是注意,运行信道高密度的应用程序可能超过这个限制。

4.6.2 多核 vs 单核处理器性能

VISA APIs 等待函数返回,因此,当等待 DSP 执行其算法时,如果你想其他线程使用处理器,您的应用程序需要是多线程的。 有关管理与 Codec Engine 相结合的多个 GPP 线程的讨论,已经超出了本文的范围。请参阅您的 GPP 操作系统 and/or 中间件文档。

4.6.3 本地性能

Codec Engine 为本地的算法执行进行了优化,执行开销和 xDAIS 算法的开销是相同的,只是创建时间略高。