similar to: Floating point implementation

Hi! It seems that using a different compiler (I assume the development is done with MSC) uncovers various issues with the floating point. Here is the second one I'm seeing - DOMAIN error from sqrt(). In the open_loop_nbest_pitch(), this line: g = DIV32(corr[i-start], 10+SHR32(MULT16_16(spx_sqrt(e0),spx_sqrt(energy[i-start]) ),6)); The values are: e0 is 7.2 i is 142, start is 17

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,

Hi, I am running speex wideband for speech. While doing that I am getting Hissing sound during silence. If you want I can give you input and output files. Thanks, Shridhar -----Original Message----- From: speex-dev-bounces@xiph.org [mailto:speex-dev-bounces@xiph.org] On Behalf Of speex-dev-request@xiph.org Sent: Tuesday, October 09, 2007 12:30 AM To: speex-dev@xiph.org Subject: Speex-dev

> Quoting Stephane Lesage <stephane.lesage at ateis-international.com>: > > Is this a bug ? Is it possible to fix it ? > > (I use version speex 1.2beta2, because newer versions just > don't work > > on my > > platform) > > This is probable the cause. 1.2beta2 was the first release to > include the resampler and it had many bugs. I suggest trying

Hello I'm testing SPEEX on embedded board using ARM7 (Atmel). ARM7 don't have floating point so I'm using FIXED_POINT. Unfortunately the encoding speed is about 5 times slower then necessary for real time. ARM7 is slow for 16/8 bits operations. The sequence: static inline spx_word32_t compute_pitch_error(spx_word16_t *C, spx_word16_t *g, spx_word16_t pitch_control) {

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

I've targeted Speex to run under eCos with Thumb interworking using arm-elf-gcc 3.3.3 I'd written a small test case to verifiy the operation: #include <speex/speex.h> void speex_test(void) { SpeexBits bits; unsigned int frame_size; void *enc_state; float *speex_frame; cyg_uint64 t1, t2; int i; speex_frame = (float *)0x00030000; /* Address of Speex data

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 =================================================================== ---

Hello Jean-Marc, > Got any luck with the Blackfin stuff? One thing I forgot mentioning that > would probably help a lot in narrowing down the bug is to simply disable > assembly functions one by one and see which one breaks Speex. sorry that I didn't reply for some days. Unfortunately I had some other serious problems with my software which are not related to Speex. I hope to solve

O.k., some more info: I just tested bandwidth widening to fix this. But I need to go to gamma values below 0.9 to become stable -- clearly too much widening, I think. I looked inside the Levinson-Durbin algorithm next. The lines #ifdef FIXED_POINT r = DIV32_16(rr+PSHR32(error,1),ADD16(error,8)); #else r = rr/(error+.003*ac[0]); #endif look interesting. While for floating point,

Hi Jean-Marc, We needed to use a release version of the SDK because this part of production code for our Sony implementations. I'm not sure how stable that branch is. Is the encoding and decoding already stable? In other words, what is not stable about that branch? Thanks, --------------------------- Saad Nader Middleware Engineer Powered By Gamespy, IGN -----Original Message----- From:

Hi, I made a small error in the impulse reponse function; when doing the inverse fft in fixed point, it will overflow unless it's properly scaled. This patch uses the same scaling as that used when updating the filters, and the outputs now have the same shape and the same scale in fixed and floating point. Best regards, Thorvald -------------- next part -------------- diff -ubBwr

I've been browsing around the speex-1.10 source tree. Firstly I see 'float' is still used in many places. Can't we change them all to the appropriate type (spx_wordxx_t or similar) defined in arch.h ? Secondly I see there is a lot of duplication regarding real-valued constants. One way would be to say: #ifndef FIXED_POINT #define CONSTANT(x) (x) #else #define CONSTANT(x)

Hi, I'll try to keep this as brief, yet descriptive enough to save everyone some time. If I'm off with this one please forgive me, but it has fixed my issues. I am not sure whether it is just my compiler (gcc 3.3.5) doing the wrong thing with the cast. File: preprocess.c Arch affected: x86, (others?) svn revision: 12778 Description: The SpeexPreprocessState_ member 'nb_adapt'

Hi Jim, First of all - thanks, turning the highpass filter off was what I needed, and the waveforms match now. But, when i did the PESQ tests again I found an interesting result : version 1.0.5 still got a slightly better average score, but the standard deviation on version 1.2 beta1 was much smaller. The cause for that is this - on some samples versions 1.0.5 and 1.2beta2 produced a single

Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: speex-1.0.5.zip Type: application/x-zip-compressed Size: 641376 bytes Desc: speex-1.0.5.zip Url : http://lists.xiph.org/pipermail/speex-dev/attachments/20071022/2447cf50/speex-1.0.5-0001.bin

Hi, I have been using speex version 1.0.5 on a text-to-speech program. Recently I upgraded to version 1.2beta1 and noticed that the waveform the I got after encoding and decoding on the new versions (beta1,beta2) is much more different than the original than on version 1.0.5. I also ran a PESQ comparison test on 700 voice samples and got better results in the older version (I used quality 9, and

--- celt/arch.h | 5 +++++ silk/macros.h | 4 +--- 2 files changed, 6 insertions(+), 3 deletions(-) diff --git a/celt/arch.h b/celt/arch.h index 9f74ddd..670527b 100644 --- a/celt/arch.h +++ b/celt/arch.h @@ -78,6 +78,11 @@ static OPUS_INLINE void _celt_fatal(const char *str, const char *file, int line) #define UADD32(a,b) ((a)+(b)) #define USUB32(a,b) ((a)-(b)) +/* Set this if opus_int64

I'm rewriting this patch for the stubs to not use outputing of raw text. Generating the instructions is very straightforward and that part is done. I'm translating the actual function now. How do you emit an .ent or .globl from asm printer? .type ? .end ?? .section ??? I'm studying the classes now but it should be simple to do so if you know, you can save me some time because this

Hello, in celt/celt_encoder.c line 369, the 'b' argument to MAX16 can sometimes be greater than what can be represented by a 16bit integer. The default definition of MAX16 is type-less, but I am working on an architecture with hardware support for min/max of 16bit. Changing the default definition to take advantage of this hardware changes the result of that computation. Please consider