# HG changeset patch # User Mychaela Falconia # Date 1683653299 0 # Node ID fcc0887ff0d02ad883883b9369610d1e2f17aa27 # Parent 5176f470489d606d2d13219cbe03874c597f2bd1 doc/FR1-Rx-DTX: document changes from 1.0.0 to 1.0.1 diff -r 5176f470489d -r fcc0887ff0d0 doc/FR1-Rx-DTX --- a/doc/FR1-Rx-DTX Tue May 09 06:56:37 2023 +0000 +++ b/doc/FR1-Rx-DTX Tue May 09 17:28:19 2023 +0000 @@ -158,3 +158,29 @@ in GSM 06.11 (3GPP TS 46.011, at the very end of the spec) is quite different. Themyscira libgsmfrp implements the correct silence frame per the spec, and that datum is also made public. + +libgsmfrp change history: version 1.0.0 to version 1.0.1 +======================================================== + +Version 1.0.0 exhibited the following defects, which are fixed in 1.0.1: + +1) The last received valid SID was cached forever for the purpose of + handling future invalid SIDs - we could have received some valid + SID ages ago, then lots of speech or NO_DATA, and if we then get + an invalid SID, we would resurrect the last valid SID from ancient + history - a bad design. In our new design, we handle invalid SID + based on the current state, much like BFI. + +2) GSM 06.11 spec says clearly that after the second lost SID + (received BFI=1 && TAF=1 in CN state) we need to gradually decrease + the output level, rather than jump directly to emitting silence + frames - we previously failed to implement such logic. + +3) Per GSM 06.12 section 5.2, Xmaxc should be the same in all 4 subframes + in a SID frame. What should we do if we receive an otherwise valid + SID frame with different Xmaxc? Our previous approach would + replicate this Xmaxc oddity in every subsequent generated CN frame, + which is rather bad. In our new design, the very first CN frame + (which can be seen as a transformation of the SID frame itself) + retains the original 4 distinct Xmaxc, but all subsequent CN frames + are based on the Xmaxc from the last subframe of the most recent SID.