Other Parts Discussed in Thread: CC2640R2F, BLE-STACK
Hello all,
I am working on the following case:
I am using the Sensortag CC2650 audio example to stream audio from Sensortag to Raspberry Pi. With Sensortag I am using BLE-Stack 2.2.1 and TI-TROS 2.20.01.08.
I am able to launch the audio example and obtain the audio using two different ways: 1) sending audio over BLE 2) sending audio via the UART interface. However, in any case I am losing audio frames in a very distinct pattern.That is, with HAR_AUDIO_MAX_ALLOC_BUF set to 10 (the default value) I can always receive the first 10 frames without any loss. The tendency remains if I change HAR_AUDIO_MAX_ALLOC_BUF to other values (tested with 5, 15, 20, 25 and 30).
To make things clearer I am attaching a snippet of the log file for audio decoding which I obtained using the modified version of the audio decoding python script (see here file "audio_frame_serial_print.py"). In the example I used HAR_AUDIO_MAX_ALLOC_BUF set to 10 and recorded audio for 10 seconds (constant HAR_STREAM_LIMIT_TIME in "sensortag_audio.c" is set to 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 |
Using this example I will explain the weird things I experienced. In the second chunk of frames (e.g. the next 10 frames) there is often one frame lost, usually at the end of the chunk or at the beginning of the third chunk as in this example. For instance, frames from 1 to 10 are received successfully so as the frames from 11 to 20, whereas the first frame of the third chunk is lost (sequence number 21). The loss of the first frame varies, but from my experiments it is usually "near" the end of the second chunk or at the beginning of the third chunk. Again the chunk size depends on HAR_AUDIO_MAX_ALLOC_BUF value and the tendency is completely the same for other values.
After the first lost frame the new tendency begins where each fifth frame after the first lost frame is lost. That is, in the example the first lost frame has a sequence number of 21, then we receive 4 frames correctly (22-25) and then again frame 26 is lost. The trend continues throughout the whole audio recording period and I did not observe any dependency on the parameters that can be tuned (e.g. HAR_AUDIO_MAX_ALLOC_BUF or HAR_STREAM_LIMIT_TIME ). To make things worse, losing one frame is the most common, but not the only option. In my numerous experimental trials I have always observed cases where two successive frames were lost. Although, this case is significantly less often than one frame loss, it is still very persistent.
I started debugging this problem and it turned out that the issue leads to the following line of code in "sensortag_audio.c":
|
1
|
tmpSeqNum = (((PDMCC26XX_pcmBuffer *)pAudioFrame)->metaData).seqNum; |
Which means that the missing sequence numbers are caused by the PDM driver not the BLE-stack or any other component. To increase the amount of available memory I disabled all other sensors as well as other services such as battery, OAD, I/O, battery and factory reset. Still the problem remains.
To me it looks like there is a bug in the PDM driver which leads to some memory issues (e.g. overflows) resulting in the frame loss. So the question to TI experts is to how to resolve this issue? Might that be the codec issue, because the frame loss has a very distinct correlation with a 4:1 compression rate (in many trials I observed the frame loss of around 25% and higher)?
Could anyone help me with this issue ?
Thank you.
Kaustubh
