opencore-amr-devel Mailing List for opencore-amr

Thanks for merging the fix! You’re right—only changing L_shl() is enough to
resolve the issue. I initially updated both for consistency, but L_shr()
doesn’t actually contribute to the problem.
On Wed, Feb 12, 2025 at 8:27 PM Martin Storsjö <ma...@ma...> wrote:
> Hi,
>
> On Wed, 5 Feb 2025, Alper Coskun wrote:
>
> > We have identified and resolved an audio distortion issue affecting
> speech
> > prompts in the AMR-WB encoder. The problem originated in hp50.c
> (HP50_12k8
> > function), where improper bit shifting and signal scaling resulted in
> > high-frequency artifacts above 4 kHz that do not exist in the original
> > signal.
> >
> > A patch has been created with the following fixes:
> >
> > • Replaced >> and << with L_shr() and L_shl() to ensure consistent
> > bit-shifting behavior.
>
> Thanks for your contribution, I've merged the fix!
>
> (Technically speaking, I guess it would have been enough to change only
> the cases with L_shl(), as L_shr() can't really overflow, or am I missing
> anything?)
>
> // Martin
>

Hi,
On Wed, 5 Feb 2025, Alper Coskun wrote:
> We have identified and resolved an audio distortion issue affecting speech
> prompts in the AMR-WB encoder. The problem originated in hp50.c (HP50_12k8
> function), where improper bit shifting and signal scaling resulted in
> high-frequency artifacts above 4 kHz that do not exist in the original
> signal.
> 
> A patch has been created with the following fixes:
> 
> • Replaced >> and << with L_shr() and L_shl() to ensure consistent
> bit-shifting behavior.
Thanks for your contribution, I've merged the fix!
(Technically speaking, I guess it would have been enough to change only 
the cases with L_shl(), as L_shr() can't really overflow, or am I missing 
anything?)
// Martin

Dear Team,
We have identified and resolved an audio distortion issue affecting speech
prompts in the AMR-WB encoder. The problem originated in hp50.c (HP50_12k8
function), where improper bit shifting and signal scaling resulted in
high-frequency artifacts above 4 kHz that do not exist in the original
signal.
A patch has been created with the following fixes:
• Replaced >> and << with L_shr() and L_shl() to ensure consistent
bit-shifting behavior.
These changes eliminate the distortion issue in affected voice prompts
while maintaining the original filter behavior.
We have attached a spectrogram comparison to illustrate the problem:
Top: Original audio (no significant energy above 4 kHz).
Middle: AMR-WB encoded output without the fix (distortion present –
excessive energy above 4 kHz).
Bottom: AMR-WB encoded output with the fix (corrected – better matches the
original).
With this patch, the AMR-WB encoder now correctly filters out
high-frequency distortions, resulting in natural-sounding speech without
unwanted artifacts.
Please find the attached patch file and spectrogram image for review. Let
us know if additional details are needed.
[image: image.png]
BR,
Alper Coskun

Hi OpenCORE-AMR Developers,
I'm writing to kindly bring your attention to the fdk-aac issue I created
at https://github.com/mstorsjo/fdk-aac/issues/167.
It would be great if someone had a chance to take a look at it.
Thanks!
Best,
Jorge

Thanks for the confirmation Martin.
Den mån 1 aug. 2022 kl 14:28 skrev Martin Storsjö <ma...@ma...>:
> On Mon, 1 Aug 2022, Johan Lantz wrote:
>
> > Great, many thanks. I will try today
> > Will the vo-amrwbenc also get updated config files?
>
> No, I don't think so unfortunately - as there's no actual code updates, I
> don't think a new release of that project is warranted just to update
> those files. The nature of the config.{guess,sub} files is that you kinda
> need to update them anytime there's a new architecture (or in this case,
> an os/arch combination which otherwise confuses the files).
>
> // Martin
>
>

On Mon, 1 Aug 2022, Johan Lantz wrote:
> Great, many thanks. I will try today
> Will the vo-amrwbenc also get updated config files?
No, I don't think so unfortunately - as there's no actual code updates, I 
don't think a new release of that project is warranted just to update 
those files. The nature of the config.{guess,sub} files is that you kinda 
need to update them anytime there's a new architecture (or in this case, 
an os/arch combination which otherwise confuses the files).
// Martin

Great, many thanks. I will try today
Will the vo-amrwbenc also get updated config files?
Den mån 1 aug. 2022 kl 13:33 skrev Martin Storsjö <ma...@ma...>:
> On 2022年7月29日, Johan Lantz wrote:
>
> > After updating config.guess and config.sub fromhere:
> https://www.gnu.org/software/gettext/manual/html_node/config_002eguess
> > .html
> >
> > it works.
>
> Hi,
>
> FWIW, I've just released a new version of opencore-amr, which should
> contain a new enough version of those files to fix your issue. But in any
> case, you often need to update those files when building older source
> packages on new platforms, for most autotools based projects.
>
> // Martin
>
>

On 2022年7月29日, Johan Lantz wrote:
> After updating config.guess and config.sub fromhere:https://www.gnu.org/software/gettext/manual/html_node/config_002eguess
> .html
> 
> it works.
Hi,
FWIW, I've just released a new version of opencore-amr, which should 
contain a new enough version of those files to fix your issue. But in any 
case, you often need to update those files when building older source 
packages on new platforms, for most autotools based projects.
// Martin

Hi,
I've released opencore-amr 0.1.6, which contains a couple minor fixes that 
have been accumulated during the last few years. It contains a fix for 
an infinite loop when decoding some bitstreams, a rather fatal issue 
though.
A packaged tarball is available on sourceforge, and the version has been 
tagged in git.
// Martin

After updating config.guess and config.sub from here:
https://www.gnu.org/software/gettext/manual/html_node/config_002eguess.html
it works.

Hi,
I have been using opencore for quite some time on iOS and it compiles fine
both for arm64 and Intel simulator using x86_64.
Now however I want to try and make my app run also in the arm64 simulator
on my M1 Mac but I am not able to successfully compile opencore for arm64
simulator. It just says: " machine `arm64' not recognized"
I use pjsip and openssl as well and both of them are compiling ok for this
combination but I am struggling with amr (the other archs for opencore are
fine).
I am really no expert on this so I could be missing something but I have
tried updating an old build script I found on github and also modifying an
openssl build script that does work for arm64/Simulator and both approaches
gives the same error.
I know this is quite specific but if anyone with more skills than me has an
M1 at hand and some ideas to share, it would be awesome.
Thank you in advance

On Thu, 3 Dec 2020, Waldron, Lewis (Lewis) wrote:
> 
> Is there a reason why the wideband encoding is not included in this project?
This project just repackages the code available from the opencore repo 
that was part of Android many years ago. That repo didn't contain code for 
an AMR-WB encoder, only decoder.
However, later, a separate repo appeared in Android, containing an AMR-WB 
encoder; that's available as a separate source project here, named 
vo-amrwbenc.
// Martin

Is there a reason why the wideband encoding is not included in this project?
Thanks
Lewis Waldron

Hi again,
This seems to be related to this code in dtx decoding for both AMR-NB and AMR-WB:
/* subtract 1/8 in Q9 (energy), i.e -3/8 dB */
st->log_en -= 64;
The value will go negative and eventually wrap to positive. This will create the noise.
I created pull request https://sourceforge.net/p/opencore-amr/code/merge-requests/3/ forcing the value to not go below zero.
Best regards,
Morten Tryfoss
Fra: Morten Tryfoss <mo...@tr...>
Dato: mandag 20. april 2020 22:00
Til: "ope...@li..." <ope...@li...>
Emne: [Opencore-amr-devel] Interpolating missing frames - AMR-WB
Hi,
I’m doing some research related to AMR-WB using Opencore-amr to give a continuous slin16 stream, both filling gaps between SID and potential lost frames.
In a case where there’s a long period of silence the decoder will have to fill 7 slin frames for very SID received. This works very well with just calling D_IF_decode() with bfi=1.
The same matter goes for interpolating "some amount" of lost frames. It seems to smooth out the stream.
However, I got into a situation where the RTP was gone for several seconds and that created some "shots" for noise about every 5-7 second.
I was also involved in investigating the "Decode all AMR-WB bits in MIME/storage file format"-commit and the noise is similar.
After some missing frames the decoder switches to state DTX_MUTE and after some time with this the noise is generated.
I’ve not confirmed, but I think the problem only occurs when the last received packet was non-speech (for example SID).
The question is, should the lib support interpolating packets for a larger time span or do the code calling the lib have to handle this outside?
Based on code comments, DTX_MUTE should just mute comfort noise and produce silence?
Best regards,
Morten Tryfoss

Hi,
I’m doing some research related to AMR-WB using Opencore-amr to give a continuous slin16 stream, both filling gaps between SID and potential lost frames.
In a case where there’s a long period of silence the decoder will have to fill 7 slin frames for very SID received. This works very well with just calling D_IF_decode() with bfi=1.
The same matter goes for interpolating "some amount" of lost frames. It seems to smooth out the stream.
However, I got into a situation where the RTP was gone for several seconds and that created some "shots" for noise about every 5-7 second.
I was also involved in investigating the "Decode all AMR-WB bits in MIME/storage file format"-commit and the noise is similar.
After some missing frames the decoder switches to state DTX_MUTE and after some time with this the noise is generated.
I’ve not confirmed, but I think the problem only occurs when the last received packet was non-speech (for example SID).
The question is, should the lib support interpolating packets for a larger time span or do the code calling the lib have to handle this outside?
Based on code comments, DTX_MUTE should just mute comfort noise and produce silence?
Best regards,
Morten Tryfoss

Just to conclude this, AMR narrowband codec is now working fine in my
baresip Android app. The only thing was that I had to add
 CXXFLAGS=-fPIC
 
argument to ./configure,
Otherwise I got linking error:
"Error: requires unsupported dynamic reloc R_ARM_REL32; recompile with -fPIC"
-- Juha

Martin Storsjö writes:
> You can check if the archive actually has got an index by running 
> "<triplet>-nm --print-armap file.a". If there is an index, you'll see 
> something like "Archive index:" with a list of symbols below it, before 
> the normal symbol listing.
Thanks for the tip. It turned out that I had forgotten to set CXX
configure flag to point to armv7a-linux-androideabi21-clang++. I had
only set CC flag and the lib is written in C++. Thus the g++ was used
during the build, which meant the ld didn't understand the resulting lib
format.
Sorry for the noice.
-- Juha

Juha Heinanen via Opencore-amr-devel writes:
> One thing comes to mind when looking at the libtool output. Why doesn't
> ar command use s flag, in which case running ranlib would not be needed?
That was not it. I edited libtool while build was in progress and added
s flag to ar and made ranlib void. Still the same issue.
-- Juha

On 2019年10月13日, Juha Heinanen wrote:
> Martin Storsjö writes:
>
>> Off-hand I have no idea. These libraries do use a pretty much standard
>> automake/libtool setup, so it should take care of running ranlib.
>>
>> Is there a difference if you build with a different version of the NDK?
>> When building, does it either invoke ranlib explicitly, or use the 's'
>> flag to ar while building the archive, to create the index at the same
>> time?
>
> Martin,
>
> Thanks for your reply.
>
> I have only tried with NDK r20, but I'm successfully building and
> linking many other libs using the same setup. So I don't think this is
> an NDK version related issue unless opencore-amr does not like clang
> that r20 and already r19 are using.
>
> Below is the last bits from the build with make "V=1" flag:
>
> /bin/bash ../libtool --tag=CC --mode=link armv7a-linux-androideabi21-clang --sysroot /opt/Android/Sdk/ndk-bundle/toolchains/llvm/prebuilt/linux-x86_64/sysroot -I../oscl -I../opencore/codecs_v2/audio/gsm_amr/amr_wb/dec/src -I../opencore/codecs_v2/audio/gsm_amr/amr_wb/dec/include -I../opencore/codecs_v2/audio/gsm_amr/common/dec/include -x c -std=c99 -fPIC -o libopencore-amrwb.la -version-info 0:3:0 -no-undefined -export-symbols ../amrwb/opencore-amrwb.sym -rpath /usr/local/lib wrapper.lo agc2_amr_wb.lo band_pass_6k_7k.lo dec_acelp_2p_in_64.lo dec_acelp_4p_in_64.lo dec_alg_codebook.lo dec_gain2_amr_wb.lo deemphasis_32.lo dtx_decoder_amr_wb.lo get_amr_wb_bits.lo highpass_400hz_at_12k8.lo highpass_50hz_at_12k8.lo homing_amr_wb_dec.lo interpolate_isp.lo isf_extrapolation.lo isp_az.lo isp_isf.lo lagconceal.lo low_pass_filt_7k.lo median5.lo mime_io.lo noise_gen_amrwb.lo normalize_amr_wb.lo oversamp_12k8_to_16k.lo phase_dispersion.lo pit_shrp.lo pred_lt4.lo preemph_amrwb_dec.lo pvamrwbdecoder.lo pvamrwb_math_op.lo q_gain2_tab.lo qisf_ns.lo qisf_ns_tab.lo qpisf_2s.lo qpisf_2s_tab.lo scale_signal.lo synthesis_amr_wb.lo voice_factor.lo wb_syn_filt.lo weight_amrwb_lpc.lo -lm
> libtool: link: arm-linux-androideabi-ar cru .libs/libopencore-amrwb.a wrapper.o agc2_amr_wb.o band_pass_6k_7k.o dec_acelp_2p_in_64.o dec_acelp_4p_in_64.o dec_alg_codebook.o dec_gain2_amr_wb.o deemphasis_32.o dtx_decoder_amr_wb.o get_amr_wb_bits.o highpass_400hz_at_12k8.o highpass_50hz_at_12k8.o homing_amr_wb_dec.o interpolate_isp.o isf_extrapolation.o isp_az.o isp_isf.o lagconceal.o low_pass_filt_7k.o median5.o mime_io.o noise_gen_amrwb.o normalize_amr_wb.o oversamp_12k8_to_16k.o phase_dispersion.o pit_shrp.o pred_lt4.o preemph_amrwb_dec.o pvamrwbdecoder.o pvamrwb_math_op.o q_gain2_tab.o qisf_ns.o qisf_ns_tab.o qpisf_2s.o qpisf_2s_tab.o scale_signal.o synthesis_amr_wb.o voice_factor.o wb_syn_filt.o weight_amrwb_lpc.o
> libtool: link: arm-linux-androideabi-ranlib .libs/libopencore-amrwb.a
> libtool: link: ( cd ".libs" && rm -f "libopencore-amrwb.la" && ln -s "../libopencore-amrwb.la" "libopencore-amrwb.la" )
>
> As you can see, ranlib is executed. I have also tried to execute it
> manually after build, but still linking fails:
>
> /opt/Android/Sdk/ndk-bundle/toolchains/llvm/prebuilt/linux-x86_64/lib/gcc/arm-linux-androideabi/4.9.x/../../../../arm-linux-androideabi/bin/ld: error: /usr/src/baresip-studio/app/src/main/cpp/../../../../distribution/amr/lib/armeabi-v7a/libopencore-amrwb.a: no archive symbol table (run ranlib)
That's weird.
(To be sure, I presume that the path that ld points out actually is an up 
to date installed version of the opencore-amr file, nothing has tried to 
strip the archive inbetween, etc?)
You can check if the archive actually has got an index by running 
"<triplet>-nm --print-armap file.a". If there is an index, you'll see 
something like "Archive index:" with a list of symbols below it, before 
the normal symbol listing.
> One thing comes to mind when looking at the libtool output. Why doesn't 
> ar command use s flag, in which case running ranlib would not be needed?
No idea, I guess it's for historical reasons, for compatibility with some 
old set of tools where the index functionality wasn't built into ar yet. 
(Otherwise I guess there wouldn't ever have been a separate ranlib tool, 
if the functionality would have been built into ar from the get go.)
// Martin

One thing comes to mind when looking at the libtool output. Why doesn't
ar command use s flag, in which case running ranlib would not be needed?
-- Juha

Martin Storsjö writes:
> Off-hand I have no idea. These libraries do use a pretty much standard 
> automake/libtool setup, so it should take care of running ranlib.
> 
> Is there a difference if you build with a different version of the NDK? 
> When building, does it either invoke ranlib explicitly, or use the 's' 
> flag to ar while building the archive, to create the index at the same 
> time?
Martin,
Thanks for your reply.
I have only tried with NDK r20, but I'm successfully building and
linking many other libs using the same setup. So I don't think this is
an NDK version related issue unless opencore-amr does not like clang
that r20 and already r19 are using.
Below is the last bits from the build with make "V=1" flag:
/bin/bash ../libtool --tag=CC --mode=link armv7a-linux-androideabi21-clang --sysroot /opt/Android/Sdk/ndk-bundle/toolchains/llvm/prebuilt/linux-x86_64/sysroot -I../oscl -I../opencore/codecs_v2/audio/gsm_amr/amr_wb/dec/src -I../opencore/codecs_v2/audio/gsm_amr/amr_wb/dec/include -I../opencore/codecs_v2/audio/gsm_amr/common/dec/include -x c -std=c99 -fPIC -o libopencore-amrwb.la -version-info 0:3:0 -no-undefined -export-symbols ../amrwb/opencore-amrwb.sym -rpath /usr/local/lib wrapper.lo agc2_amr_wb.lo band_pass_6k_7k.lo dec_acelp_2p_in_64.lo dec_acelp_4p_in_64.lo dec_alg_codebook.lo dec_gain2_amr_wb.lo deemphasis_32.lo dtx_decoder_amr_wb.lo get_amr_wb_bits.lo highpass_400hz_at_12k8.lo highpass_50hz_at_12k8.lo homing_amr_wb_dec.lo interpolate_isp.lo isf_extrapolation.lo isp_az.lo isp_isf.lo lagconceal.lo low_pass_filt_7k.lo median5.lo mime_io.lo noise_gen_amrwb.lo normalize_amr_wb.lo oversamp_12k8_to_16k.lo phase_dispersion.lo pit_shrp.lo pred_lt4.lo preemph_amrwb_dec.lo pvamrwbdecoder.lo pvamrwb_math_op.lo q_gain2_tab.lo qisf_ns.lo qisf_ns_tab.lo qpisf_2s.lo qpisf_2s_tab.lo scale_signal.lo synthesis_amr_wb.lo voice_factor.lo wb_syn_filt.lo weight_amrwb_lpc.lo -lm 
libtool: link: arm-linux-androideabi-ar cru .libs/libopencore-amrwb.a wrapper.o agc2_amr_wb.o band_pass_6k_7k.o dec_acelp_2p_in_64.o dec_acelp_4p_in_64.o dec_alg_codebook.o dec_gain2_amr_wb.o deemphasis_32.o dtx_decoder_amr_wb.o get_amr_wb_bits.o highpass_400hz_at_12k8.o highpass_50hz_at_12k8.o homing_amr_wb_dec.o interpolate_isp.o isf_extrapolation.o isp_az.o isp_isf.o lagconceal.o low_pass_filt_7k.o median5.o mime_io.o noise_gen_amrwb.o normalize_amr_wb.o oversamp_12k8_to_16k.o phase_dispersion.o pit_shrp.o pred_lt4.o preemph_amrwb_dec.o pvamrwbdecoder.o pvamrwb_math_op.o q_gain2_tab.o qisf_ns.o qisf_ns_tab.o qpisf_2s.o qpisf_2s_tab.o scale_signal.o synthesis_amr_wb.o voice_factor.o wb_syn_filt.o weight_amrwb_lpc.o
libtool: link: arm-linux-androideabi-ranlib .libs/libopencore-amrwb.a
libtool: link: ( cd ".libs" && rm -f "libopencore-amrwb.la" && ln -s "../libopencore-amrwb.la" "libopencore-amrwb.la" )
As you can see, ranlib is executed. I have also tried to execute it
manually after build, but still linking fails:
/opt/Android/Sdk/ndk-bundle/toolchains/llvm/prebuilt/linux-x86_64/lib/gcc/arm-linux-androideabi/4.9.x/../../../../arm-linux-androideabi/bin/ld: error: /usr/src/baresip-studio/app/src/main/cpp/../../../../distribution/amr/lib/armeabi-v7a/libopencore-amrwb.a: no archive symbol table (run ranlib)
-- Juha

Moikka,
On 2019年10月13日, Juha Heinanen via Opencore-amr-devel wrote:
> I built libopencore-amrwb.a and libopencore-amrnb.a static libraries
> using NDK r20 and then tried to use them in my baresip Android app.
> However, NDK linker complains that there is no symbol table in the
> libraries:
>
> /opt/Android/Sdk/ndk-bundle/toolchains/llvm/prebuilt/linux-x86_64/lib/gcc/arm-linux-androideabi/4.9.x/../../../../arm-linux-androideabi/bin/ld: error: /usr/src/baresip-studio/app/src/main/cpp/../../../../distribution/amr/lib/armeabi-v7a/libopencore-amrwb.a: no archive symbol table (run ranlib)
>
> Library build went without issues with this kind of configure and make
> commands:
>
> CC="armv7a-linux-androideabi21-clang --sysroot /opt/Android/Sdk/ndk-bundle/toolchains/llvm/prebuilt/linux-x86_64/sysroot" RANLIB=arm-linux-androideabi-ranlib AR=arm-linux-androideabi-ar PATH=/opt/Android/Sdk/ndk-bundle/toolchains/llvm/prebuilt/linux-x86_64/bin:/usr/bin:/bin ./configure --host=arm-linux-androideabi --disable-shared CFLAGS="-fPIC" && \
> CC="armv7a-linux-androideabi21-clang --sysroot /opt/Android/Sdk/ndk-bundle/toolchains/llvm/prebuilt/linux-x86_64/sysroot" RANLIB=arm-linux-androideabi-ranlib AR=arm-linux-androideabi-ar PATH=/opt/Android/Sdk/ndk-bundle/toolchains/llvm/prebuilt/linux-x86_64/bin:/usr/bin:/bin make
>
> Any idea what the problem is?
Off-hand I have no idea. These libraries do use a pretty much standard 
automake/libtool setup, so it should take care of running ranlib.
Is there a difference if you build with a different version of the NDK? 
When building, does it either invoke ranlib explicitly, or use the 's' 
flag to ar while building the archive, to create the index at the same 
time?
// Martin

I built libopencore-amrwb.a and libopencore-amrnb.a static libraries
using NDK r20 and then tried to use them in my baresip Android app.
However, NDK linker complains that there is no symbol table in the
libraries:
/opt/Android/Sdk/ndk-bundle/toolchains/llvm/prebuilt/linux-x86_64/lib/gcc/arm-linux-androideabi/4.9.x/../../../../arm-linux-androideabi/bin/ld: error: /usr/src/baresip-studio/app/src/main/cpp/../../../../distribution/amr/lib/armeabi-v7a/libopencore-amrwb.a: no archive symbol table (run ranlib)
Library build went without issues with this kind of configure and make
commands:
CC="armv7a-linux-androideabi21-clang --sysroot /opt/Android/Sdk/ndk-bundle/toolchains/llvm/prebuilt/linux-x86_64/sysroot" RANLIB=arm-linux-androideabi-ranlib AR=arm-linux-androideabi-ar PATH=/opt/Android/Sdk/ndk-bundle/toolchains/llvm/prebuilt/linux-x86_64/bin:/usr/bin:/bin ./configure --host=arm-linux-androideabi --disable-shared CFLAGS="-fPIC" && \
CC="armv7a-linux-androideabi21-clang --sysroot /opt/Android/Sdk/ndk-bundle/toolchains/llvm/prebuilt/linux-x86_64/sysroot" RANLIB=arm-linux-androideabi-ranlib AR=arm-linux-androideabi-ar PATH=/opt/Android/Sdk/ndk-bundle/toolchains/llvm/prebuilt/linux-x86_64/bin:/usr/bin:/bin make
Any idea what the problem is?
-- Juha

Hi,
I just released fdk-aac 2.0.1. This just contains a number of crash/fuzz 
fixes.
The new version is available for download as a tarball at sourceforge, and 
is available tagged in git on both sourceforge and github.
// Martin

Hi,
I now released fdk-aac 2.0.0, which is based on a new rather large 
upstream code drop, with new features (which partially break old API) and 
lots of crash fixes.
The new version is available as a tarball on sourceforge and tagged in git 
on both github and sourceforge.
// Martin