Hi Vadim, > > It looks like OBB reads from a_dd_0 (TCH/F or TCH/H subchannel 0) or > > a_dd_1 (TCH/H subchannel 1) to get DL data traffic bits, and for > > transmitting UL, it relies on the same debug-only hack-feature of the > > DSP that is used in "TCH play" mechanism in FreeCalypso, accessible > > via fc-shell 'tch play' command. > > yes, it was done like that before my patches.
The actual history, in forward chronological order, is something like this: 1) For debug purposes only, TI made the intermediate interface between speech enc/dec and channel enc/dec blocks accessible to the ARM core by placing those a_dd_x & a_du_x buffers in the NDB API RAM page, instead of non-ARM-accessible DSP private RAM. 1a) As a further debug/test feature, they implemented "UL play" mode in which the output of the speech encoder can be suppressed and replaced (at channel encoder input) with externally supplied bits. This debug feature is NOT used by any of TI's production firmwares! 2) At some point (seems to be early in project history) OBB folks discovered the existence of DSP debug features 1 & 1a, probably by noticing conditioned-out (not actually compiled, and won't work if enabled) code in TSM30 and LoCosto L1 sources that uses this mechanism for an external loopback test where some instrument such as CMU200 receives UL and loops it back to DL. It was discovered that this mechanism can be (ab)used to route DL voice to somewhere other than the phone's earpiece speaker, and to source UL voice from somewhere other than the phone's built-in mic; OBB thus acquired support for such redirected voice operation. 3) Some time in late 2015 or early 2016 I was approached by some "mystery" people (the kind who felt I had no need to know who they were or what they were doing) who asked for a similar feature in FreeCalypso. Mind you, this development was in early 2016 at the latest, we had no FC Magnetite yet, not even FC Citrine, all we had was the original "FreeCalypso GSM fw" that was utterly broken and unusable. But I was badly in need of money, hence I agreed to work with said "shadowy" people and implemented the feature they asked for. Unfortunately I don't even know if that customer actually got what they wanted for their money: because they were so secretive, the exact requirements weren't communicated clearly, and I never received any feedback. But that is how support for TCH tap modes appeared for the first time in FreeCalypso. 4) My own attempts to use that commercially-sponsored TCH Rx feature for more standard and open (no weird secrets) voice communication were a failure back in 2016. Back then I incorrectly thought that the output of GSM 05.03 channel decoder goes directly to the input of GSM 06.10 speech decoder (I was only playing with FRv1 at the time), but there was a key missing piece: the Rx DTX handler block, which implements BFI handling, SID detection, error concealment and comfort noise insertion, has to go between the other two blocks. (Looking at the world of gapk and related support in OBB, I get a feeling that Osmocom people at the time made the same oversight as I did.) Trying to feed TCH DL Rx directly to libgsm produced horrible sounds, hence I shelved the idea, and it remained shelved for years. 5) In 2022, in connection with my new work on the network side of GSM, I learned the proper structure of this chain: 05.03 channel decoder -> Rx DTX handler -> 06.10 speech decoder When I implemented libgsmfrp for the Rx DTX handler function (now subsumed into libgsmfr2), I revisited the TCH tap feature of our dear Calypso, and voila, it actually works when the decoder chain is implemented correctly! That's how we got present-day TCH DL sniffing and TCH UL substitution support in current FC. 6) On OBB side, when you took on the task of adding CSD support, you must have discovered that the same mechanism that was previously used to route voice externally (in raw codec-bits form) can also be used to receive DL and feed UL for CSD. You may or may not have known at the time that this DSP feature is only a debug mode not meant for production use - but you do know now. :) [HR CSD problem in OsmoBTS] > Ack, this is a known problem. We don't have a ticket for it, so you're > welcome to create one ;) OS#6577. [TCH/F4.8 NT handling] > The problem is that `desc->num_blocks` is 2 for TCH/F4.8 NT, so the > for-loop in csd_v110_rtp_encode() iterates only 2 (not 4) times, and > thus `(i >> 1) & 0x01` never evaluates to 1 in this channel mode. Yes, that's exactly how I concluded (from reading the code only, having no test setup) that the logic is currently wrong. > Here is my attempt to fix the Uplink part of the problem: > https://gerrit.osmocom.org/c/osmo-bts/+/38301 Unfortunately I had to CR-2 this patch: this approach can't possibly work because bit E7 (and the entire group of NIC bits) does not exist in NT mode. As I wrote in Gerrit, the only workable solution here is to pass an additional flag to the function from outside, indicating the alignment position with respect to the 26-multiframe. An example of how the same problem is addressed on GSM MS side: https://www.freecalypso.org/hg/fc-tourmaline/file/tip/src/cs/layer1/cfile/l1_cmplx.c#l5072 Basically we have to figure out the correct frame numbers (may be different for network vs MS, will have to check) and pass a flag into CSD V.110 encoding function, only for this one mode. > Here is a WIP/draft patch for the Downlink part, currently just dropping > RTP packets carrying unaligned halves: > > https://gerrit.osmocom.org/c/osmo-bts/+/38303 [WIP] > > For TCH/9.6 we can just swap the two halves in case they're not aligned. > For TCH/4.8 we can store unaligned halves in some buffer... What we really need to do is force an artificial phase shift in the Rx jitter buffer if and when we detect that the phase of the incoming RTP stream does not match the phase needed for radio DL output. (I have no spare mental capacity for AMR currently, but I suspect a similar problem exists there in terms of CMI/CMR phase: what if the incoming RTP stream changes actually-used modes out-of-phase with CMI frame positions on the DL?) And since we have to deal with the jitter buffer here, this brings us to: I propose that we pause this effort until after we address the idea of making themwi-rtp-lib an optional alternative to libortp. When using themwi-rtp-lib, I can produce quite elegant implementation of whatever phase shifts are needed, whether for TCH/F4.8 NT or for AMR CMI/CMR; but libortp is a bone in my throat. Speaking of which: I need to update OS#6474 with the current status of themwi-rtp-lib... > I did not foresee this problem, thanks for pointing it out. Likewise, > feel free to create a ticket! OS#6578. Effort to be continued... M~ _______________________________________________ Community mailing list [email protected] https://www.freecalypso.org/mailman/listinfo/community
