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. |
