opencore-amr-devel Mailing List for opencore-amr
Audio codecs extracted from Android Open Source Project
Brought to you by:
mstorsjo
You can subscribe to this list here.
2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(28) |
Aug
(7) |
Sep
(3) |
Oct
|
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2011 |
Jan
|
Feb
|
Mar
(9) |
Apr
(1) |
May
(5) |
Jun
(7) |
Jul
(3) |
Aug
(1) |
Sep
|
Oct
(2) |
Nov
(5) |
Dec
|
2012 |
Jan
(4) |
Feb
(2) |
Mar
(3) |
Apr
(4) |
May
(3) |
Jun
|
Jul
(8) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
(4) |
Dec
|
2014 |
Jan
(11) |
Feb
(4) |
Mar
(8) |
Apr
(9) |
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
(8) |
Nov
|
Dec
|
2015 |
Jan
(5) |
Feb
(1) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2017 |
Jan
(2) |
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(7) |
Dec
|
2018 |
Jan
(1) |
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(9) |
Nov
|
Dec
|
2020 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(2) |
2022 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
(5) |
Sep
|
Oct
|
Nov
|
Dec
|
2024 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2025 |
Jan
|
Feb
(3) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Alper C. <alp...@gm...> - 2025-02-13 08:06:12
|
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 > |
From: Martin S. <ma...@ma...> - 2025-02-12 17:27:45
|
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 |
From: Alper C. <alp...@gm...> - 2025-02-05 07:24:21
|
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 |
From: Jorge S. L. <jor...@ca...> - 2024-02-22 15:37:49
|
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 |
From: Johan L. <ila...@gm...> - 2022-08-01 12:41:58
|
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 > > |
From: Martin S. <ma...@ma...> - 2022-08-01 12:28:50
|
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 |
From: Johan L. <ila...@gm...> - 2022-08-01 12:02:29
|
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 Fri, 29 Jul 2022, 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 > > |
From: Martin S. <ma...@ma...> - 2022-08-01 11:33:46
|
On Fri, 29 Jul 2022, 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 |
From: Martin S. <ma...@ma...> - 2022-08-01 11:31:31
|
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 |
From: Johan L. <ila...@gm...> - 2022-07-29 16:18:22
|
After updating config.guess and config.sub from here: https://www.gnu.org/software/gettext/manual/html_node/config_002eguess.html it works. |
From: Johan L. <ila...@gm...> - 2022-07-28 21:24:18
|
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 |
From: Martin S. <ma...@ma...> - 2020-12-03 08:31:31
|
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 |
From: Waldron, L. (Lewis) <lw...@av...> - 2020-12-03 07:57:51
|
Is there a reason why the wideband encoding is not included in this project? Thanks Lewis Waldron |
From: Morten T. <mo...@tr...> - 2020-04-21 11:39:53
|
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 |
From: Morten T. <mo...@tr...> - 2020-04-20 20:00:14
|
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 |
From: Juha H. <jh...@tu...> - 2019-10-16 07:33:50
|
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 |
From: Juha H. <jh...@tu...> - 2019-10-13 20:25:18
|
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 |
From: Juha H. <jh...@tu...> - 2019-10-13 20:00:43
|
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 |
From: Martin S. <ma...@ma...> - 2019-10-13 19:54:52
|
On Sun, 13 Oct 2019, 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 |
From: Juha H. <jh...@tu...> - 2019-10-13 19:41:13
|
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 |
From: Juha H. <jh...@tu...> - 2019-10-13 19:27:21
|
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 |
From: Martin S. <ma...@ma...> - 2019-10-13 18:57:16
|
Moikka, On Sun, 13 Oct 2019, 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 |
From: Juha H. <jh...@tu...> - 2019-10-13 17:25:00
|
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 |
From: Martin S. <ma...@ma...> - 2019-10-08 13:16:06
|
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 |
From: Martin S. <ma...@ma...> - 2018-11-22 11:39:34
|
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 |