FreeCalypso > hg > gsm-codec-lib
comparison doc/FR1-library-history @ 301:019eed8b1948
doc/FR1-library-history: new article
author | Mychaela Falconia <falcon@freecalypso.org> |
---|---|
date | Mon, 15 Apr 2024 18:36:21 +0000 |
parents | doc/FR1-Rx-DTX@731c98b67da1 |
children | 516e84085a15 |
comparison
equal
deleted
inserted
replaced
300:be7ae099cbc3 | 301:019eed8b1948 |
---|---|
1 The first Themyscira library for GSM-FR speech codec was libgsmfrp, an add-on | |
2 to legacy libgsm from TU-Berlin. The current offering is libgsmfr2, which | |
3 supplants the earlier combination of libgsm+libgsmfrp. This document details | |
4 the change history in this continuum of GSM-FR codec libraries. | |
5 | |
6 Changes from libgsmfrp version 1.0.2 to libgsmfr2 version 2.0.0 | |
7 =============================================================== | |
8 | |
9 * Dependency on <gsm.h> defined types abolished, the entire library uses | |
10 <stdint.h> types instead. | |
11 | |
12 * The Rx DTX handler component of the new library is unchanged from libgsmfrp | |
13 version 1.0.2, aside from the use of new types: uint8_t instead of gsm_byte, | |
14 explicit arrays of uint8_t instead of gsm_frame. | |
15 | |
16 * In addition to this Rx DTX handler component, the new library includes the | |
17 GSM 06.10 encoder & decoder component (ported from libgsm pl22), the new | |
18 full decoder wrapper with decoder homing, an encoder homing function, and | |
19 new stateless frame packing and unpacking functions. | |
20 | |
21 libgsmfrp change history: version 1.0.1 to version 1.0.2 | |
22 ======================================================== | |
23 | |
24 There are only two changes, both involving corner cases with invalid SID frames | |
25 being received: | |
26 | |
27 1) An invalid SID frame was received immediately following a good speech frame. | |
28 In this case we start CN generation, but we take the needed LARc and Xmaxc | |
29 parameters from the last speech frame, instead of the usual procedure of | |
30 extracting them from a valid SID frame. The change from 1.0.1 to 1.0.2 | |
31 concerns the Xmaxc parameter in this corner case: in 1.0.1 we took Xmaxc | |
32 from the last subframe and used it for ensuing CN generation, but in 1.0.2 | |
33 we compute a more proper mean Xmaxc from all 4 subframes, by dequantizing, | |
34 summing and requantizing. | |
35 | |
36 2) An invalid SID frame was received in the speech muting state. The sequence | |
37 of inputs would have to be: | |
38 | |
39 - a good speech frame; | |
40 - one or more BFIs, but not too many, so that the cached speech frame | |
41 does not decay fully by Xmaxc reduction; | |
42 - an invalid SID frame. | |
43 | |
44 In version 1.0.1 we handled this even more obscure corner case by entering | |
45 the CN muting state, i.e., the state that is normally entered upon the | |
46 second lost SID. In version 1.0.2 we ignore invalid SID in the speech | |
47 muting state and act as if we got BFI, i.e., continue speech muting rather | |
48 than switch to CN muting. | |
49 | |
50 libgsmfrp change history: version 1.0.0 to version 1.0.1 | |
51 ======================================================== | |
52 | |
53 Version 1.0.0 exhibited the following defects, which are fixed in 1.0.1: | |
54 | |
55 1) The last received valid SID was cached forever for the purpose of | |
56 handling future invalid SIDs - we could have received some valid | |
57 SID ages ago, then lots of speech or NO_DATA, and if we then get | |
58 an invalid SID, we would resurrect the last valid SID from ancient | |
59 history - a bad design. In our new design, we handle invalid SID | |
60 based on the current state, much like BFI. | |
61 | |
62 2) GSM 06.11 spec says clearly that after the second lost SID | |
63 (received BFI=1 && TAF=1 in CN state) we need to gradually decrease | |
64 the output level, rather than jump directly to emitting silence | |
65 frames - we previously failed to implement such logic. | |
66 | |
67 3) Per GSM 06.12 section 5.2, Xmaxc should be the same in all 4 subframes | |
68 in a SID frame. What should we do if we receive an otherwise valid | |
69 SID frame with different Xmaxc? Our previous approach would | |
70 replicate this Xmaxc oddity in every subsequent generated CN frame, | |
71 which is rather bad. In our new design, the very first CN frame | |
72 (which can be seen as a transformation of the SID frame itself) | |
73 retains the original 4 distinct Xmaxc, but all subsequent CN frames | |
74 are based on the Xmaxc from the last subframe of the most recent SID. |