FreeCalypso > hg > freecalypso-docs

comparison DSP-speech-decoder @ 108:e26623146358 default tip

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
new article DSP-speech-decoder
author Mychaela Falconia <falcon@freecalypso.org>
date Tue, 29 Oct 2024 22:11:41 +0000
parents
children
comparison
equal deleted inserted replaced
107:dfa5f99631a6 108:e26623146358
1 As described in Calypso-digital-voice article, we can use Calypso MCSI (an
2 auxiliary hardware interface brought out on FreeCalypso dev boards) in the so-
3 called "Bluetooth headset" mode to capture the voice call downlink in digital
4 form, specifically 16-bit linear PCM, after speech decoding performed by the
5 DSP, but before D-to-A conversion for analog audio output. As of 2024-10, we
6 have a set of tools (Lattice Icestick FPGA board, a gateware design for this
7 FPGA, and corresponding host software tools - see fc-pcm-if Hg repository) that
8 puts these ideas into practice; using these tools, we can now answer some long-
9 standing questions about exactly how Calypso DSP implements speech decoding for
10 various GSM codecs.
11
12 FRv1 decoder implementation
13 ===========================
14
15 The original set of Full Rate codec specs did not include the feature of in-band
16 encoder and decoder homing frames; this feature was included in HRv1 and EFR
17 from day 1, and was also back-ported to FRv1 in later versions of 06.10 spec -
18 but it was not present originally, and it is defined as optional in the later
19 spec versions. Going into these Calypso MCSI experiments, we had this question:
20 does Calypso DSP implement decoder homing frames for FRv1, or does it not?
21 Experimental observation: in-band decoder homing is NOT implemented for FRv1 in
22 this DSP. If we feed the DHF defined in later versions of 06.10 spec to our
23 Calypso MS via TCH DL, it gets treated as a regular speech frame without any
24 special handling; more specifically, we don't see PCM16 output frames consisting
25 of 0x0008 words as required by the spec when the optional in-band decoder homing
26 feature is present.
27
28 This lack of in-band homing feature makes it difficult to test the decoder
29 against official ETSI test sequences, as we have no way of getting it into a
30 defined state. The ancient GSM 11.10 test spec provides a mechanism called DAI
31 that includes the necessary reset signal, and it appears that Calypso DSP does
32 support operating MCSI as DAI rather than "Bluetooth" mode - but we haven't done
33 any experiments with this DAI mode yet. Hence our exploration of FRv1 decoder
34 implementation in our dear Calypso DSP ends here for now.
35
36 EFR decoder implementation
37 ==========================
38
39 Unlike the situation with FRv1, the in-band codec homing feature is mandatory
40 for EFR per the specs. And with Calypso DSP we got good news: it does implement
41 this feature at least in the decoding direction, which is the only one we've
42 tested so far. Exactly per the spec, the first DHF arriving from TCH DL is
43 decoded like a regular speech frame, but the decoder state is reset at the end.
44 All subsequent DHFs turn into 0x0008 output, and we indeed see the latter coming
45 out on MCSI.
46
47 Once we established that the decoder homing feature works as specified, our
48 next question was: does our dear Calypso DSP implement the original bit-exact
49 definition of EFR, or does it implement what we call the AMR-EFR hybrid?
50 Experimental observation: at least in the decoding direction, it implements the
51 original bit-exact EFR decoder! This finding is remarkable because all of our
52 experiments in this series were performed on DSP ROM version 3606, the final
53 one that not only includes AMR support, but has been subject to whatever rework
54 TI did between 3416 and 3606 ROMs. If we assume (based on some experiments in
55 past years where we disabled loading of TI's official DSP patches) that AMR
56 support is already present in the DSP ROM, as opposed to being contained
57 entirely in the patches, it follows that the DSP ROM must contain both EFR and
58 AMR codec implementations, yet the EFR implementation has not been AMR-ized.
59 (In contrast, the network-side speech transcoder implementation used by T-Mobile
60 USA and Telcel Mexico appears to use maximally-shared code between EFR and AMR,
61 resulting in the AMR-EFR hybrid that differs from the original bit-exact
62 definition, but has been blessed by 3GPP as an acceptable alternative.)
63
64 Strange corruption bug
65 ----------------------
66
67 As we fed ETSI test sequences from GSM 06.54 to our Calypso DSP under test via
68 TCH DL, checking for an exact match, we observed what appears to be a corruption
69 bug of some kind (corrupting either codec parameter bits or state variables)
70 that manifests in a manner that seems random. In our test, we concatenated all
71 21 test sequences from GSM 06.54 (test0.cod through test20.cod) and fed the
72 resulting super-long sequence into TCH DL. The test was performed twice; on
73 the second try we had 'tch record' running in fc-shell, capturing TCH DL as
74 received by the Calypso MS, and we confirmed that the entire super-long test
75 sequence was received without errors. The decoded output (captured via MCSI)
76 was then split into 21 separate robe files following frame counts: because each
77 test*.cod input sequence begins with two DHFs, the decoder resets between these
78 concatenated test sequences, allowing the output to be compared against
79 test*.out reference files with per-sequence granularity. The final diff
80 comparison between split-out robe files and the official reference decoder
81 output revealed the following oddities:
82
83 * In the first run, decoded outputs for test0, test6, test11, test14, test15,
84 test16 and test20 showed a mismatch. The difference in test0 outputs was
85 examined closer: the diff begins on a subframe boundary and continues until
86 the next DHF. All other test sequences got a perfect match to ETSI reference
87 decoder output.
88
89 * In the second run, a different set of sequences showed a mismatch: this time
90 the failing sequences were test1, test5, test6, test7, test15 and test16.
91 The other sequences that produced mismatches in the first run produced
92 perfectly good output (matching ETSI reference decoder) in this run!
93
94 * test6, test15 and test16 were the three sequences that failed in both runs.
95 However, diffing between the two runs shows that the errors in each of these
96 3 twice-failed sequences are different between runs, further strengthening
97 the appearance of corruption that seems totally random.
98
99 We do not currently have any better explanation for this oddity than a data
100 corruption bug somewhere in the DSP. For the record, these tests were performed
101 on an FCDEV3B with Calypso DSP ROM version 3606 and DSP patch version 6840.