Attention is currently required from: falconia, pespin. laforge has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-bts/+/32968 )
Change subject: all models, HR1 codec: accept both TS101318 and RFC5993 formats ...................................................................... Patch Set 1: (2 comments) File src/common/l1sap.c: https://gerrit.osmocom.org/c/osmo-bts/+/32968/comment/bdfb60f4_9d13fcc2 PS1, Line 1270: case GSM_HR_BYTES_RTP_RFC5993: > so here we remove the ToC information. […] the question is: do we have any existing code that would require it? It's not really useful to think about hypothetical constraints by theoretical future other DSP Backends. We're in 2023 and it is very unlikely that there will still be people developing new GSM BTS hardware for osmo-bts... https://gerrit.osmocom.org/c/osmo-bts/+/32968/comment/ec110390_2ad09b3c PS1, Line 1279: memmove(msg->data, msg->data + 1, GSM_HR_BYTES); : msgb_get(msg, 1); I'm wondering why we are moving data around in the msgb? This is potentially quite expensive on our poor ARM926 based platforms, thinking of doing this for 14 TCH/H channels, for each RTP frame. Can't we simply msgb_pull(msg, 1), i.e. make the pointers to the start of the message point one byte further into the msgb? -- To view, visit https://gerrit.osmocom.org/c/osmo-bts/+/32968 To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmo-bts Gerrit-Branch: master Gerrit-Change-Id: I702e26c3ad5b9d8347e73c6cd23efa38a3a3407e Gerrit-Change-Number: 32968 Gerrit-PatchSet: 1 Gerrit-Owner: falconia <fal...@freecalypso.org> Gerrit-Reviewer: Jenkins Builder Gerrit-CC: laforge <lafo...@osmocom.org> Gerrit-CC: pespin <pes...@sysmocom.de> Gerrit-Attention: falconia <fal...@freecalypso.org> Gerrit-Attention: pespin <pes...@sysmocom.de> Gerrit-Comment-Date: Wed, 24 May 2023 13:53:02 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Comment-In-Reply-To: pespin <pes...@sysmocom.de> Gerrit-MessageType: comment
