similar to: Symbol visibility control in static builds

If building a static library, marking symbols as dllexport causes them to be exported from the final executable. For example, run objdump -x opus_demo.exe on a --disabled-shared build and look for the export table; there should not be one in a normal Win32 .exe file, but when linking static libopus, the exe exports all of the opus_* public functions. Use the libtool-defined DLL_EXPORT flag to

Hi, I'm planning to use Opus codec on a ARM cortex M7 device running at 400MHz. Con you please suggest the best configuration directives that I have to set in the config.h file in order to obtain the best perfromances on the cortex M7 architecture? Actually I have compiled libopus 1.2.1 with the following cnfiguration parameters: #define VAR_ARRAYS  1 #define FIXED_POINT  1 #define

Hi everyone, I have lately been evaluating the performance of various audio decoders, particularly for ARM devices (Cortex A8 / A9). The context is audio playback in a game engine, and thus decoding performance is of particular interest. Looking at Opus versus Vorbis on a Cortex A9 smartphone, the numbers look approximately like this: Vorbis (tremolo decoder) 9.3 Mb PCM/s Opus (libopus 1.1)

Hi, Thank you for your response. I pulled yesterday to commit da97db1ca1f92592af3534c9a2596da0e9a009ca, added a bunch of more defines to my compile options, and assembled & linked in armopts.s,celt_pitch_xcorr_arm.s. Performance jumped up from about 4.8 Mb/s to 5.3 Mb/s on the same device, so it is improvement. Not sure what other tweaks there would be to try, but if it could match the

Hi Dan, I suggest you try the code in git master, which has further ARM optimizations compared to 1.1. Cheers, Jean-Marc On 04/09/14 08:00 AM, Dan Nilsson wrote: > Hi everyone, > > I have lately been evaluating the performance of various audio decoders, > particularly for ARM devices (Cortex A8 / A9). The context is audio > playback in a game engine, and thus decoding

Just wondering if anyone might be seeing any similar frequent crashes of Firefox/GNOME/Nautilus lately. I have a couple of users who have reported a problem like this. Any ideas are welcome. Latest CentOS 5.5 w/patches, latest nVidia graphics driver, firefox from repos. | ###!!! ABORT: Request 0.0: BadRequest (invalid request code or no such | operation): file nsX11ErrorHandler.cpp, line 182 |

EL8: Since the new update of firefox (rebased), I get a lot of coredumps while playing videos. Anyone experiencing the same? Aug 30 16:44:05 work.localdomain systemd-coredump[27017]: Process 21016 (firefox) of user 1006 dumped core. Stack trace of thread 21016: #0

Pursuing some rpm verify errors exposed while investigating my T'bird/FF problem, a prelink -am gives this, and other, error. prelink: /usr/lib/esc-1.0.0/xulrunner/xulrunner-bin: Could not find one of the dependencies Ran # ldd /usr/lib/esc-1.0.0/xulrunner/xulrunner-bin|grep 'not found' libmozjs.so => not found libxpcom.so => not found libxul.so =>

https://bugs.freedesktop.org/show_bug.cgi?id=75279 --- Comment #19 from Benoit Jacob <bjacob at mozilla.com> --- A duplicate Mozilla bug has a stack with symbols: https://bugzilla.mozilla.org/show_bug.cgi?id=975512#c1 #0 0x0000003f3a2da007 in sched_yield () from /lib64/libc.so.6 #1 0x00007f1e003bb1d1 in nouveau_fence_wait () from /usr/lib64/dri/nouveau_dri.so #2 0x00007f1e0039d635

https://bugs.freedesktop.org/show_bug.cgi?id=75279 --- Comment #28 from Frederic Bezies <fredbezies at gmail.com> --- Some progress with debug packages. But I think I'll need xf86-video-nouveau debug package too. At least, here is the log : (gdb) bt full #0 0x00007f364503a337 in sched_yield () from /usr/lib/libc.so.6 No symbol table info available. #1 0x00007f3632d0e411 in

Hi all! What is the right way to report bugs in libopus? I couldn't find any publicly available bugtracker. Anyway, the problem I need to report is that some source files in libopus are missing copyright headers. This breaks license check script that we use in chromium to validate licenses for third-party dependencies. Specifically the following files don't have copyright header:

Hi Opus Experts, I am working on a JNI library which depends on libopusenc which in turn depends on libopus. However, during runtime, I encountered a linking error while loading the library: java.lang.UnsatisfiedLinkError: dlopen failed: cannot locate symbol "opus_projection_encoder_ctl" referenced by "libopusenc.so" Here is how to reproduce the issue: Build procedure

Hi Some Linux programs are 'static'. For example, these FFmpegs here ---> http://ffmpeg.gusari.org/static/ If we compile with Linux opusdec & opusenc & opusinfo & opusrtp using only static libraries libogg.a & libflac.a & libopus.a Are the four opus-tools programs then genuinely 'static', so that they will work on *any* Linux OS? $ ./opusenc -V opusenc

Hi Drew, I've had some time to dig more deeply into your patch. Here's some more in-depth comments: 1) I note that your OpusMSEncoder struct in private.h adds a subframe_mem[] that's not in opus_multistream_encoder.c. I assume it's due to a merge problem (that field was removed some time ago), but can you confirm/fix the issue? 2) I noticed your patch adds many OPUS_EXPORT

From: Thierry Reding <treding at nvidia.com> Checks whether or not the compiler supports the -fvisibility option. If so it sets the VISIBILITY_CFLAGS variable which can be added to the per directory AM_CFLAGS where appropriate. By default all symbols will be hidden via the VISIBILITY_CFLAGS. The drm_public macro can be used to mark symbols that should be exported. Signed-off-by: Thierry

On 30/07/14 15:31, Rob Clark wrote: > On Wed, Jul 30, 2014 at 9:48 AM, Thierry Reding > <thierry.reding at gmail.com> wrote: >> From: Thierry Reding <treding at nvidia.com> >> >> Checks whether or not the compiler supports the -fvisibility option. If >> so it sets the VISIBILITY_CFLAGS variable which can be added to the per >> directory AM_CFLAGS

The attached small configury patch extends visibility attributes usage to darwin (osx) builds. Tested by cross-compiling on a linux host using gcc-.4.0.2 and gcc-4.2.1 against 10.4 and 10.6 SDKs. Regards. -- O.S. -------------- next part -------------- diff --git a/configure.ac b/configure.ac index 6d0fa00..d3c302a 100644 --- a/configure.ac +++ b/configure.ac @@ -395,7 +395,6 @@ if test

Hi Drew, We're getting there... Some minor comments: 1) The public header file should not have an #ifdef ENABLE_EXPERIMENTAL_AMBISONICS since that would require the user code to define it. 2) Why do you have #define MAPPING_MATRIX_C ? 3) Looks like MAPPING_MATRIX_MAX_SIZE is not longer useful, right? 4) Even though it's not strictly necessary here, please add parentheses to the

Here's another one. On Thu, Nov 2, 2017 at 9:54 AM Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > Hi Drew, > > We're getting there... Some minor comments: > > 1) The public header file should not have an > #ifdef ENABLE_EXPERIMENTAL_AMBISONICS > since that would require the user code to define it. > > Done > 2) Why do you have #define

Hi Drew, Thanks for the update. Your patch is now in master. Now, it would be good if you could think of a way to reduce the stack usage as we discussed. Cheers, Jean-Marc On 11/07/2017 04:28 PM, Drew Allen wrote: > Here's another patch. Cheers! > > On Mon, Nov 6, 2017 at 10:08 AM Drew Allen <bitllama at google.com > <mailto:bitllama at google.com>> wrote: >