Attention is currently required from: laforge, dexter. falconia has posted comments on this change. ( https://gerrit.osmocom.org/c/libosmocore/+/32685 )
Change subject: codec: replace GSM-FR ECU with new implementation ...................................................................... Patch Set 2: (1 comment) Patchset: PS2: > My general comment to this is that the current ECU interface is not set in > stone. If you think there's a way to bring it more in-line with what the > specs intend to do, and it's not rewriting half of osmo-bts, I'd be > interested to hear/read about it. Regarding osmo-bts: I argue that a BTS should never be applying any ECU to its uplink at all. There *may* be a case for applying an ECU-like transform in the downlink path, if one were to take the rules of TS 28.062 section C.3.2.1.1 (written for TFO) and interpret them as also applying to TrFO - but even there I am not totally convinced. My main cause for hesitation in that case is that those C3211 rules are easy to implement for FR1 codec (just call a standard FR1 Rx DTX handler implementation such as Themyscira libgsmfrp), but seem inordinately difficult and awkward for EFR or HR1. (If someone has an actual legacy TRAU they could hook up to OCTOI so I could experiment with it, I would love to poke around and see what historical vendors actually did there!) A much much simpler alternative to trying to implement C3211 rules would be to simply induce a deliberate BFI condition on call B DL when a BFI was received from call A UL, and that's exactly what osmo-bts already does without any ECU: osmo-bts-trx sends dummy FACCH, whereas sysmoBTS PHY sends out a traffic frame with CRC3 bits inverted, thereby inducing a BFI condition in the MS receiver. (I say so based on observing what the Calypso DSP receives when a zero-length payload has been fed to sysmoBTS PHY in the DL.) Beyond osmo-bts, regarding the ECU concept in general: I am still not convinced that a standalone ECU (not part of a full speech decoder emitting a block of 160 linear PCM samples on its output) should exist at all! I don't see any reason for one to exist, nowhere do any specs call for such a thing, and it would be very difficult to implement one for any codec other than FR1. For HR1 and all later codecs, the ECU function has been baked into the main decoder from the get-go, and never implemented or even defined as a standalone component. FR1 is the lone exception, but even for FR1 the modular piece that is defined as separable from the main decoder is not an ECU, but a slightly bigger piece called the Rx DTX handler. Again, why should a separate ECU-by-itself exist at all, what need is there for one? This kind of deep technical discussion of which functionality should exist at a high level (higher level than code review details) is exactly what OsmoDevCall seems best suited for. I already added an FR/EFR codecs topic proposal to the OsmoDevCall wiki page, and I see absolutely nothing scheduled past May. It would be so much easier if we could talk about this FR/EFR codecs, ECUs etc topic in proper depth in June ODC! -- To view, visit https://gerrit.osmocom.org/c/libosmocore/+/32685 To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: libosmocore Gerrit-Branch: master Gerrit-Change-Id: I0200e423ca6165c1313ec9a4effc3f3047f5f032 Gerrit-Change-Number: 32685 Gerrit-PatchSet: 2 Gerrit-Owner: falconia <[email protected]> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: dexter <[email protected]> Gerrit-CC: laforge <[email protected]> Gerrit-Attention: laforge <[email protected]> Gerrit-Attention: dexter <[email protected]> Gerrit-Comment-Date: Thu, 11 May 2023 13:18:30 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Comment-In-Reply-To: laforge <[email protected]> Gerrit-MessageType: comment
