在我们的项目中、我们 将在 ARM/Linux 处理器上接收音频数据、将数据放入共享存储器区域、然后传送 DSP/BIOS 来执行音频数据的处理。 一旦 DSP 完成音频处理、则会将相同的 IPC 消息返回至 ARM、表示处理完成、并可能会发送下一条消息。 此过程按预期运行、但需注意一点；随着 DSP 处理音频数据所用的时间增加、ARM 接收 DSP 返回消息和音频后处理所需的时间也增加。 开销的增加大约为 DSP 处理其工作所花费时间的18%。
我们测试了 ARM/Linux 应用程序来测量用于各种 DSP 工作的单条消息的往返时间。 下面是测量表：
|
Linux 单调耗时往返 TX/RX 时间(毫秒) |
DSP 处理延迟(毫秒) |
开销(毫秒) |
延迟百分比形式的开销 |
|
0.15 |
0 |
0.15 |
100 |
|
6.27 |
5 |
1.27 |
20.25518341 |
|
12.38 |
10 |
2.38 |
19.22455574 |
|
24.58 |
20 |
4.58 |
18.63303499 |
|
36.79 |
30 |
6.79 |
18.4561022 |
当 DSP 不执行任何工作时、IPC 消息需要0.15ms 往返时间。 我们假设这是 ARM 和 DSP 之间往返数据包的"基本"开销。 随着 DSP 上的处理延迟的增加、开销也会增加。 我们期望往返时间应接近 DSP 处理延迟+基本开销(.15ms)加上/减去一些小差异。 但我们发现、开销随着 DSP 处理的增加而增加。 如果您从 ARM/Linux 端进行的所有往返测量中减去基本开销(.15ms)、开销大约为 DSP 上进行处理所花费时间的18%。
我们正在尝试了解这种额外开销来自哪里？ 我们已尝试了以下所有功能、但仍然看到相同的行为：
- 非 RT 内核与 RT 内核
- 作为 RT 运行 Linux 线程与不运行 RT
- 从 L2SRAM 运行 DSP 与从 DDR 运行 DSP (与 Linux 共享)
- 将 DSP RX 消息队列单独移至 L2SRAM (在 DDR 中含代码)
- 具有或不具有在 ARM 上运行的任何其他进程-除了内置/标准进程(在非 RT 与 RT 内核中涉及)
- Task_sleep ()作为 DSP 中的延迟与硬编码 NOP 环路相比在实际音频处理中的延迟
- 轮询返回数据包的 RX MessageQ 与永远等待
作为完整性检查、我还使用库存工具执行了完全相同的实验、 IPC_3_50_04_08/exmaamples/66AK2G_Linux_elf/ex02_MessageQ 链路演示应用程序。 我所做的唯一改动是、在接收消息之后、在返回消息之前、在 Linux 应用程序中添加计时仪表、并在 DSP 中添加固定的延迟。
在 应用程序 c 我添加了
Clock_gettime (clock_monotonic、&start_mono)；
在 App_exec() 在分配和添加消息之前
Clock_gettime (clock_monotonic、&end_mono)；
diff = 1000000000 *(end_mono.tv_sec - start_mono.tv_sec)+ end_mono.tv_nsec - start_mono.tv_nsec；
printf ("rt：%llu 纳秒\n"、diff)；
fflush (stdout)；
从 DSP 再次接收并释放消息之后执行最后一次写入。
在 server.c 我添加了
Task_sleep (X)；
在 server_exec() 在收到消息后、但在返回之前。
这一采用"样本"消息队列演示应用的实验得到的结果是相同的。 随着 DSP 中 X 的值增加、往返开销也增加；往返时间不仅仅是基本开销(.15ms)+ Task_sleep (X)、它大约是基本开销(.15ms)+ Task_sleep (X)+.18 (Task_sleep (X)。
我们希望有人可以帮助了解这种额外开销来自哪里？
谢谢。
杰里米
