Thread 中讨论的其他器件：CC2640R2F、 BLE-STACK
大家好、
我正在处理以下案例：
我使用 Sensortag CC2650 音频示例将音频从 Sensortag 流式传输 到 Raspberry Pi。 有 了 Sensortag、我将使用 BLE-Stack 2.2.1 和 TI-TROS 2.20.01.08。
我能够启动音频示例并通过两种不同的方式获取音频：1)通过 BLE 发送音频2)通过 UART 接口发送音频。 但是、在任何情况下、我都会以非常独特的模式丢失音频帧。也就是说 、在 HAR_AUDIO_MAX_ALLOC_BUF 设置为10 (默认值)的情况下、我始终可以接收前10帧而不会丢失任何数据。 如果我将 HAR_AUDIO_MAX_ALLOC_BUF 更改为其他值(使用5、15、20、25和30进行测试)、则趋势仍然存在。
为了更清楚地说明、我要附加一个用于音频解码的日志文件片段、我使用音频解码 Python 脚本的修改版本获得了该文件(请参阅 此处 的文件"Audio 帧串行打印.py")。 在示例中、我使用 了 HAR_AUDIO_MAX_ALLOC_BUF 设置为10并录制了音频10秒( "sensortag_audio.c"中的恒定 HAR_STREALL_TIMER 设置为10000)。
|
1
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18
19.
20.
21.
22.
23
24
25
26
27.
28.
29.
30
31.
32
33.
34
35.
36.
37.
38.
39.
40
41.
42.
43.
44.
45.
46.
47.
48
49
50
51.
52.
53.
54
55
56.
57.
58.
59.
60
61.
62.
63.
64
65
66
67
68
69
70
71.
72.
73.
74.
75
76.
77
78
79
80
81.
82.
83.
84
85.
86
87
88
89
90
91.
92
93
94
95
96
97
98
99
100
101.
102.
103.
104.
105.
106.
107.
108.
109.
110
111.
112
113
114
115
116
117
118
119
|
Frame sequence number: 1 HDR_1 local: 0, HDR_1 received: 0 HDR_2 local: 0, HDR_2 received: 0 Frame sequence number: 2 HDR_1 local: 18, HDR_1 received: 18 HDR_2 local: -136, HDR_2 received: -136 Frame sequence number: 3 HDR_1 local: 20, HDR_1 received: 20 HDR_2 local: 2, HDR_2 received: 2 Frame sequence number: 4 HDR_1 local: 26, HDR_1 received: 26 HDR_2 local: -129, HDR_2 received: -129 Frame sequence number: 5 HDR_1 local: 14, HDR_1 received: 14 HDR_2 local: -33, HDR_2 received: -33 Frame sequence number: 6 HDR_1 local: 14, HDR_1 received: 14 HDR_2 local: -139, HDR_2 received: -139 Frame sequence number: 7 HDR_1 local: 16, HDR_1 received: 16 HDR_2 local: -108, HDR_2 received: -108 Frame sequence number: 8 HDR_1 local: 25, HDR_1 received: 25 HDR_2 local: -148, HDR_2 received: -148 Frame sequence number: 9 HDR_1 local: 22, HDR_1 received: 22 HDR_2 local: -75, HDR_2 received: -75 Frame sequence number: 10 HDR_1 local: 39, HDR_1 received: 39 HDR_2 local: 295, HDR_2 received: 295 Frame sequence number: 11 HDR_1 local: 38, HDR_1 received: 38 HDR_2 local: -391, HDR_2 received: -391 Frame sequence number: 12 HDR_1 local: 29, HDR_1 received: 29 HDR_2 local: -28, HDR_2 received: -28 Frame sequence number: 13 HDR_1 local: 23, HDR_1 received: 23 HDR_2 local: -153, HDR_2 received: -153 Frame sequence number: 14 HDR_1 local: 23, HDR_1 received: 23 HDR_2 local: -7, HDR_2 received: -7 Frame sequence number: 15 HDR_1 local: 19, HDR_1 received: 19 HDR_2 local: -61, HDR_2 received: -61 Frame sequence number: 16 HDR_1 local: 14, HDR_1 received: 14 HDR_2 local: -62, HDR_2 received: -62 Frame sequence number: 17 HDR_1 local: 34, HDR_1 received: 34 HDR_2 local: -304, HDR_2 received: -304 Frame sequence number: 18 HDR_1 local: 29, HDR_1 received: 29 HDR_2 local: 127, HDR_2 received: 127 Frame sequence number: 19 HDR_1 local: 26, HDR_1 received: 26 HDR_2 local: 126, HDR_2 received: 126 Frame sequence number: 20 HDR_1 local: 31, HDR_1 received: 31 HDR_2 local: -114, HDR_2 received: -114 Frame sequence number: 22 HDR_1 local: 35, HDR_1 received: 35 HDR_2 local: 146, HDR_2 received: 146 ######################### MISSED ######################### 1 ########################################################## Frame sequence number: 23 HDR_1 local: 38, HDR_1 received: 38 HDR_2 local: 119, HDR_2 received: 119 Frame sequence number: 24 HDR_1 local: 31, HDR_1 received: 31 HDR_2 local: -187, HDR_2 received: -187 Frame sequence number: 25 HDR_1 local: 23, HDR_1 received: 23 HDR_2 local: -73, HDR_2 received: -73 Frame sequence number: 27 HDR_1 local: 28, HDR_1 received: 28 HDR_2 local: -166, HDR_2 received: -166 ######################### MISSED ######################### 1 ########################################################## Frame sequence number: 28 HDR_1 local: 22, HDR_1 received: 22 HDR_2 local: 11, HDR_2 received: 11 Frame sequence number: 29 HDR_1 local: 25, HDR_1 received: 25 HDR_2 local: 37, HDR_2 received: 37 Frame sequence number: 30 HDR_1 local: 36, HDR_1 received: 36 HDR_2 local: 294, HDR_2 received: 294 Frame sequence number: 0 HDR_1 local: 20, HDR_1 received: 20 HDR_2 local: -14, HDR_2 received: -14 ######################### MISSED ######################### 1 ########################################################## Frame sequence number: 1 HDR_1 local: 31, HDR_1 received: 31 HDR_2 local: -292, HDR_2 received: -292 Frame sequence number: 2 HDR_1 local: 39, HDR_1 received: 39 HDR_2 local: -415, HDR_2 received: -415 Frame sequence number: 3 HDR_1 local: 25, HDR_1 received: 25 HDR_2 local: 142, HDR_2 received: 142 Frame sequence number: 5 HDR_1 local: 27, HDR_1 received: 27 HDR_2 local: 197, HDR_2 received: 197 ######################### MISSED ######################### 1 ########################################################## ... saving file ...DONE... Frames lost: 168 Frames received: 658 |
使用此示例、我将解释我遇到的怪异情况。 在第二个块的帧 (例如接下来的10个帧)中、通常会丢失一个帧、通常在第三个块的末尾或在第三个块的开头、如本例所示。 例如、从1到10的帧被成功接收、这样从11到20的帧、而第三个块的第一个帧丢失(序列编号21)。 第一个帧的丢失有所不同、但从我的实验来看、它通常"接近"第二个块的末尾或第三个块的开头。 同样、块大小取决于 HAR_AUDIO_MAX_ALLOC_BUF 值、其他值的趋势完全相同。
在第一个丢失帧后、新的趋势开始、第一个丢失帧后的每五个帧丢失。 也就是说、在示例中、第一个丢失帧的序列号为21、然后我们正确接收4个帧(22-25)、然后再次丢失帧26。 这种趋势在整个音频录制期间持续，我没有观察到对可调参数的任何依赖(例如 Har_AUDIO_MAX_ALLOC_BUF 或 HAR_STREAM_LIMIT_TIME )。 更糟糕的是、丢失一个帧是最常见的、但不是唯一的选择。 在我的许多试验中，我一直观察到连续两帧丢失的情况。 虽然这种情况比丢失一帧的频率要低得多、但仍然非常持久。
我开始调试这个问题、结果发现这个问题导致"sensortag_audio.c"中的以下代码行：
|
1
|
tmpSeqNum = (((PDMCC26XX_pcmBuffer *)pAudioFrame)->metaData).seqNum; |
这意味着丢失的序列号是由 PDM 驱动程序而不是 BLE-STACK 或任何其他组件引起的。 为了增加可用存储器的容量、我禁用了所有其他传感器以及其他服务、例如电池、OAD、I/O、电池和工厂复位。 问题仍然存在。
在我看来、PDM 驱动程序中有一个错误、这会导致一些内存问题(例如溢出)、从而导致帧丢失。 那么、TI 专家面临的问题是如何解决这个问题？ 这可能是编解码器的问题、因为帧丢失与 4：1压缩率具有非常明显的相关性(在许多试验中、我观察到帧丢失约为25%及更高)？
有人能帮我解决这个问题吗？
谢谢你。
考乌什
