similar to: Library export file for Win32 (patch)

Hi, I've attached a patch against SVN r14645 which adds GCC visibility information to all symbols exported from libspeex.so and libspeexdsp.so. It includes a configure.ac change to test that both the compiler flags and __attribute__((visibility)) works, and if so will #define EXPORT __attribute__((visibility("default"))) and if not #define EXPORT I've attached a diff output

Hi, I've attached a patch against SVN r14645 which adds GCC visibility information to all symbols exported from libspeex.so and libspeexdsp.so. It includes a configure.ac change to test that both the compiler flags and __attribute__((visibility)) works, and if so will #define EXPORT __attribute__((visibility("default"))) and if not #define EXPORT I've attached a diff output

Hi, I am using speex 1.2beta2 on a narrowband 16-bit, 8khz system that has a severe program space problem and will not fit speex in its normal operation. In an attempt to shrink speex I placed a breakpoint in every function and ran a decode and encode and removed the breakpoints that I hit. in the functions that had a breakpoint that I didn't hit I commented out those functions (as well as

for the bits init I am using speex_bits_set_bit_buffer and I don't use the write to or read from because the data is already in the buffer I am reading from and I am writing to the final buffer so I don't need to move arrays around. what part is the vocoder part of the decode? Thanks for your help! -Mike >>> Jean-Marc Valin <jean-marc.valin@usherbrooke.ca> 08/06/07

Thank you, I really appreciate the help. -Mike >>> Jean-Marc Valin <jean-marc.valin@usherbrooke.ca> 08/07/07 8:34 AM >>> Michael Jacobson a ?crit : > I'm glad to hear that my data size can be shrunk considerably, > however I do not know the minimum values that I would set the static > arrays to be. I hate to be a bother but could you tell me the >

I'm glad to hear that my data size can be shrunk considerably, however I do not know the minimum values that I would set the static arrays to be. I hate to be a bother but could you tell me the minimum values for these arrays/structures in the state structure? Thanks! encode: stack winBuf excBuf swBuf lagWindow old_lsp old_qlsp mem_sp mem_sw mem_sw_whole mem_exc mem_exc2 pi_gain pitch

Hi. Le duodi 2 frimaire, an CCXIV, Wesley J. Landaker a ?crit?: > speexenc always crashes on amd64; here is an example, and lots of info: I tracked this bug a bit further than you. Here is the origin of the crash: op.packet = (unsigned char *)speex_header_to_packet(&header, (int*)&(op.bytes)); (from speexenc.c) op.bytes is a long, not an int, it is wrong to pass it as an int,

i'm optimizing some features....for exemple why not doing this : ------------------------------------------------------------------------------- void speex_bits_advance(SpeexBits *bits, int n) { if (((bits->bytePtr<<3)+bits->bitPtr+n>bits->nbBits) || bits->overflow){ bits->overflow=1; return; } bits->bytePtr += (bits->bitPtr+nbBits) >>

> Oops... You've just found a bug. Seems like you're the first one to use > that call. Anyway, it's now fixed in CVS (both trunk and 1.0.x branch). > Thanks for the bug report. Hmm, the call to speex_encode_stereo() takes the frame size as an an argument - and this call generates bits ;) So possibly my bitrate table shows wrong values in the stereo cases. Hmm... Where would

hi this code gives me a warning: SpeexStereoState stereo = SPEEX_STEREO_STATE_INIT; modules/speex/mod.c: In function 'alloc': modules/speex/mod.c:61: warning: missing initializer modules/speex/mod.c:61: warning: (near initialization for 'stereo_init.reserved1') would it be possible to add this patch to you svn ? Index: include/speex/speex_stereo.h

Dear Jean-Marc and Peter: Thank you both very much for your time and advice. I did not realize that Lame MP3 code has a -r option (without reading its code). I have tried the suggested command lines verbatim with the added -r option, along with other combination of option settings. I could not figure out how to eliminate the distortion in the result, like voice turning either high or low

Well, I don't quite understand why AC_C_BIGENDIAN and the solution you're proposing is likely to break other big endian machines (the ones that don't have __BIG_ENDIAN__). Can you send a patch that addresses that (i.e. still uses AC_C_BIGENDIAN when it works)? Jean-Marc Peter Grayson a ?crit : > Hi all, > > Speex currently decides endianness at configure-time. This causes

Hi all, Speex currently decides endianness at configure-time. This causes the ppc half of Mac universal binaries to have some endianness problems. Most notably, the header built by speex_packet_to_header() has incorrect byte-ordering. This Apple developer page describes the incantation that can be used to build universal binaries on Mac. It also highlights the configure-time versus compile-time

Hi there. I am having a little trouble understanding the frame sizes chosen by the codec. testenc_uwb.c from the speex-1.0 source distribution has a framesize of 640 hardcoded and makes use of this value exclusively. However, a mode query on the actual codec returns 320 as a framesize for this mode. int tmp; speex_mode_query(&speex_uwb_mode, SPEEX_MODE_FRAME_SIZE, &tmp);

On Fri, Apr 4, 2008 at 12:19 AM, Jean-Marc Valin <jean-marc.valin at usherbrooke.ca> wrote: > Jahn, Ray (R.) a ?crit : > > > Dear Speex codec community: > > > > I am working on conversion of voice files. I could not figure out how to use speexdec.exe 1.2.3 in piped mode in order to avoid the creation of the potentially large intermediate *.wav or *.pcm files. Any

Hi Jean-Marc, Hi Jim, I have also seen some problems with the 1.1.8 release on the C55x. So far I have boiled down the issues to the following: 1) We need our own "fixed_xx.h" header file. I don't know why, and haven't had time to investigate, but there is a definite improvement when I use the attached fixed_c55x.h file which has turned all the maths into inline functions.