similar to: Small bug fixed

Hi Jean-Marc, As I told you, bank is a reserved keyword in Analog Devices compiler for Blackfin architecture. So we need to change the variables named bank to something else. Here's a patch that changes bank to bnk in the 3 concerned files. (Hope the format is OK) About my previous problems with the Blackfin: -> strange block repetition that could be cancelled by the AEC I was busy

You have the point. "I get very distorted speech when using libspeex in my application. What¡¯s wrong? .... If the input speech has an amplitude close to ¡¾2^15, it is possible that at decoding, the amplitude be a bit higher than that, causing clipping when saving as 16-bit PCM." This is one of FAQs in 'speex-manual' you wrote. I guess amplitudes close to 2^15 bother me. Do

Could someone point me to the BARK/MEL tables that these macros (from vorbis/scales.h) are trying to approximate? #define toBARK(f) (13.1*atan(.00074*(f))+2.24*atan((f)*(f)*1.85e-8)+1e-4*(f)) #define fromBARK(z) (102.*(z)-2.*pow(z,2.)+.4*pow(z,3)+pow(1.46,z)-1.) #define toMEL(f) (log(1.+(f)*.001)*1442.695) #define fromMEL(m) (1000.*exp((m)/1442.695)-1000.) I was wondering if I could come

Hello to everyone! During building speex library for Symbian OS I encountered some problems. All thess problems can be solved by modifying the speex sources. I don't have access to SVN repository of speex, so I will just describe the changes to be done: 1) mmp file in symbian derictory misses windows.c sources. You need to add this string into speex.mmp: SOURCES windows.c 2) Symbian OS

Hi All, I need some clarifications regarding the mismatch I found in the code and the specification. (a) In the specification, the bark(x) equation is given as: bark(x) = 13.1 atan(.00074x) + 2.24 atan(.0000000158(x^2)) + .0001x whereas in the code it is given as: #define toBARK(n) (13.1f*atan(.00074f*(n))+2.24f*atan((n)*(n)*1.85e-8f)+1e-4f*(n)) Which one of these is the proper one ? (b)

Hi, I'm trying to use a denoiser on a wince with a FIXED_POINT defined. Denoiser works OK - it removes the noise, but then it unacceptable hurts a voice. Here is a code that I use: #define TEST_DENOISE_SAMPLES 2000 void test_denoise() { FILE *fin; FILE *fout; spx_int32_t rate=0; int chan=1; int fmt=16; int denoise_enabled = 1; SpeexPreprocessState *preprocess;

Hello, Filterbank.c does not compile on visual studio because of the declaration of : int id1; int id2; in the filterbank_new() procedure (line 45) id1 and id2 must be compiled in the begin of the procedure... Ouss

Hi, In the course of some work which I describe below, I have found a very significant difference between the BARK function described in the Vorbis specification and its implementation in libvorbis. In the specificationhttp://xiph.org/vorbis/doc/Vorbis_I_spec.pdf bark(x) = 13.1arctan(.00074x) + 2.24arctan(.0000000185x**2 + .0001x) In the libvorbis code

https://bugs.freedesktop.org/show_bug.cgi?id=105097 Bug ID: 105097 Summary: Computer hangs only mouse moves Product: xorg Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Driver/nouveau Assignee: nouveau at

Hi all, i'm using speex under symbian. When i have compiled the lib for ARM platform i have obtained the follow error: "Error: Can not represent OFFSET_IMM8 relocation in this object file format (1)" I have defined FIXED_POINT 1 and ARM4_ASM. The error is in the function forced_pitch_quant contained in ltp.c. The line that produce the error is:

I have a small feature request for oggenc: Can a command line option be added to allow the user to set the first serial number to be used for the output ogg stream? This only takes a few lines of code, actually. Rationale: it is quite helpful for debugging other encoders. If oggenc is the "reference" encoder, ensuring that your new whiz-bang encoder has diffable output to oggenc is a

Hi all I have spent the last three days evaluating CELT on our supported platforms. I found a bug in quant_bands.c, that due to processor/compilation differences did not cause an issue on x86 platforms, but is a problem on the MIPS processor embedded devices. When decoding on the MIPS devices, there was a lot of noise added during the decoding, the noise is mainly in the 15 khz to 21 khz range.

hi, I am using speex1.2beta2 on a TI 54x on narrow band I have been trying to get speex to work for a while now, and it's been a real teeter-totter ride. For a long time I noticed that I will get a project to work and then without changing any code and programming it to an eprom/flash the project will not work. It turns out it was a value called innov_save. I found this bugger by zero

yes, our DSP is 16 bit based, and if those bits of code aren't using 32 bit variables then yes that is what the warnings would be. Does this mean that the preprocessor and echo canceller won't work as well because of this? -Mike >>> Jean-Marc Valin <jean-marc.valin@usherbrooke.ca> 01/18/08 8:42 PM >>> I think these warnings are due to your DSP being 16-bit and

Hi, I'm using 1.2beta3 on a 5416 DSP I have been getting warning messages that say: "kiss_fft.c", line 142: warning: shift count is too large I've noticed this on the echo canceller and the preprocessor. all pretty much related to these two lines of code: kiss_fft C_MUL4(scratch[0],Fout[m] , *tw1 ); mdf.c st->wtmp2[i] =

Did you check it against the trunk in SVN? If it's not applied, and you can hook Jean-Marc up with an email address like yours, I'm sure he will get right on it. :) Tom Mihai Balea <mihai@hates.ms> wrote: > > Hi all, > > Did anything happen to this patch? > It seems to me that it fixes a valid issue, but I'm not an expert. > Anyways, I didn't see

> misc.c provides the ability to override some functions, including the > allocation and printing. fftwrap.c uses speex_alloc, then calls > kiss_fftr_alloc, which calls kiss_fft_alloc, which calls KISS_FFT_MALLOC, > which is defined as malloc in kiss_fft.h. It would make it more consistent > to define KISS_FFT_MALLOC as speex_alloc. That is the only change that I > would

There is a problem in speex_preprocess_ctl. Both speech_prob_start and speech_prob_continue are set to 327.67 for all input values except 0 which results in 0. This is in floating point mode. I think the included patch fixes the problem. Mikael -------------- next part -------------- Index: libspeex/preprocess.c =================================================================== ---

Hi, I am using 1.2beta2 on a C5416 doing narrowband in the decode function I am having a problem with the execution of my program vectoring off to random interrupts that are not used. I have tracked down the error to the highpass function called in nb_decode -very close to the end of the function-context: it is called here: ln 1719 for me if (st->highpass_enabled) highpass(out,

Jim Crichton a ?crit : > I played briefly with the echo canceller on the C5509A back in May > 2006. I got the same compiler warnings, and sent a message to the > list which included this: > > "I got several compiler warnings for "shift out of range" in mdf.c, > which I fixed by adding EXTEND32 to all of the SHL32s with 16 bit > operands (st->frame_size in 6