search

traud / asterisk-gsm-efr

Asterisk 13 transcoding module: GSM-EFR
The Unlicense
3 stars 3 forks source link

Nokia Mobile Phones: Distorted Audio #1

Open traud opened 8 years ago

traud commented 8 years ago

support GSM-EFR. By the way, Symbian/S60 does not offer GSM-EFR. However, the audio sounds distorted in both directions. sRTP did not make a difference. GSM-EFR not transcoded but passed-through works between those clients. Pass-through with the Google Android implementation gives the same distorted audio. Google re-orders the speech bits like in AMR. Perhaps, Nokia does not do this re-ordering. That should be tested first.

All these clients support AMR.

jobrown22 commented 4 years ago

@traud I see a similar issue when using newer phones. Wondering what you mean by "Google re-orders the speech bits like in AMR"? Is there a spec I can take a look at to arrange them correctly with native applications that don't use the "re-ordering" instead of the Google SIP client?

traud commented 4 years ago

First of all, this is just a guess. The cause could be anything. In other words, I would start to look at that first. That fork of the OpenCORE-AMR library used in this project here (and the original one used by Google Android) does reordering: bitreorder_tab.cpp. That is based on 3GPP TS 26.101 chapter 4.2.1: ‘The … encoder output … are ordered according to their subjective importance …’ (which then refers to Appendix B). That is a chapter about AMR. The corresponding chapter for GSM-EFR is 4.4.1. My understanding: Yes, with GSM-EFR, do the same re-ordering as with AMR.

Now, comes the problem: RFC 3551 chapter 4.5.9 was created before that ‘chapter’ was added in 3GPP TS 26.101. The RFC refers to ETSI TS 101 318 chapter 5.3. And that does not say anything about re-ordering; at least I am reading it that way.

Consequently, I would compile the latest version of ‘our’ OpenCORE-AMR library†, and disable that re-ordering just for testing. Then, you have to make sure that changed library is usedby Sangoma Asterisk; instead of the system-provided one. For this, you have to re-configure Asterisk, provide the library in the path (compile and link) and fiddle around with the run path (-rpath):

// within the directory of your OpenCORE-AMR build
./configure
make
cd amrnb/.libs
export OPENCORE_NB_HOME=$PWD
…
// within the directory of your Sangoma Asterisk
LDFLAGS="-Wl,-rpath=$OPENCORE_NB_HOME" ./configure --with-opencore-amrnb="$OPENCORE_NB_HOME"
make
sudo make install

That is just a rough idea/sketch; I never tried/tested that myself. Again, this might not be the cause. However, this would be my next step if I were working on this issue. If that was not the cause, my next idea is to double-check the endianness (which one?!). By the way, if you have an idea for the cause, anything is welcome!

Because of this, which looks like a bug in the specification, creating an interoperability issue which nobody ever is able to resolve, I did not continue with this issue, especially because all my affected devices also offer AMR. What is your use-case that you have to deal with GSM-EFR? If you do not like to share that here in public, you can send me a private mail (my E-mail is included in every commit). I am curious!

† Depending on your Linux distribution, you might be better off using the source of your distribution instead of the original source code.

traud commented 4 years ago

Yes, the bit ordering is the culprit. The following patch turns OpenCORE-AMR into a library for (just) GSM-EFR: patch.txt