similar to: Info on Symbian, ARM and OFFSET_IMM8 relocation error

Displaying 20 results from an estimated 500 matches similar to: "Info on Symbian, ARM and OFFSET_IMM8 relocation error"

2008 Jan 22
2
Shift count warning messages
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
2008 Jan 23
2
Shift count warning messages
Thanks Jim for looking into that, I was really starting to wonder what was going on. Let me know if you find a way to tell the compiler to stop complaining. Jean-Marc Jim Crichton a ?crit : > I looked back at my old C55 EC build, and I had the same warning in > mdf.c which Mike found. The assembly code did have a valid shift, and > this build did cancel echo. > > When I built
2006 May 10
2
Speex echo canceller on TI C55 DSP
> 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
2008 Jan 26
1
Shift count warning messages
Hi Jim, Thanks a lot for investigating. It definitely makes sense now. I'll fix the problem now. Is there any other place where you see that same (or similar) problem? Jean-Marc Jim Crichton a ?crit : > Jean-Marc, > > I dug into this further, and found that the warning occurred when PSHR32 > had a shift greater than 15. > > in fixed_generic.h, PSHR32 is defined as: >
2008 Jan 22
2
Shift count warning messages
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
2007 Apr 13
3
Symbian and buffer of 4096 bytes
I'm using speex under symbian (8000 hz, 16 bit) narrow band. The phones API only give me a buffer of 4096 bytes in recording.To reproduce audio I must fill up the buffer of the same dimension. 4096 isn't a multiple of 320. I want encode the audio in streaming. The solution that I adopt to encode is: - Divide 4096-256 bytes in 12 frames of 320 bytes. - Therefore the frame number 13 is
2006 Apr 21
2
Major internal changes, TI DSP build change
> The C5x and C6x output diverges in build 10143, which has log message "lpc > floor converted to fixed-point." Also, the measured SNR changed from 11.05 > in builds 9854-10141 to 9.22 and 9.24 in 10143. Actually, build 10143 introduced another bug, that was the reason for the 1.1.11.1 release. > There is just four lines in modes.c which declare the constant, and one
2006 May 10
2
Speex echo canceller on TI C55 DSP
> Build 11387 produces the same result as my modified build 11343. Because of > compiler limitations in the TI tools, I did have to make modifications to > pseudofloat.h (separating return of float values) and nb_celp.c (adding > braces around a variable declaration in the middle of code). I have > attached a patch. You might prefer to do the nb_celp.c change in a >
2005 May 26
2
Speex on TI C6x, Problem with TI C5x Patch
Jean-Marc, >> > It's odd that it "almost" works with the fixed_generic.h. The easiest >> > thing would be to gradually replace routines and see which one causes >> > problem. It's most likely (though I'm not 100% sure) that somewhere in >> > the code, I have a 16-bit value that gets sent to a function/macro that >> > expects a
2010 Jun 15
2
AEC init crashes
Hello, I've just caught a strange crash in speex_echo_state_init routine. It happened only on one WinXP machine, while on others using XP, Vista and 7 everything is fine. Crash occures in mdf.c line 434: st->spec_average = DIV32_16(SHL32(EXTEND32(st->frame_size), 15), st->sampling_rate); Got any ideas or should I provide more information of the OS? Thanks a lot!
2006 Apr 18
2
Major internal changes, TI DSP build change
> I was wrong, it is the encoder that is not working, and it stopped working > in build 11103. The log message for this build is "another 640 bytes > removed from the encoder state (using the input data instead of copying it > to st->frame/st->inBuf)". Only nb_celp.c/h are changed in this build. What > I am seeing out of the decoder is an extremely low signal
2008 Jan 22
0
Shift count warning messages
Mike, 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 places, st->wtmp2 in 1 place)." I sent
2008 Jan 25
0
Shift count warning messages
Jean-Marc, I dug into this further, and found that the warning occurred when PSHR32 had a shift greater than 15. in fixed_generic.h, PSHR32 is defined as: #define PSHR32(a,shift) (SHR32((a)+((1<<((shift))>>1)),shift)) For 16-bit compilers the "1" needs a cast: #define PSHR32(a,shift) (SHR32((a)+((EXTEND32(1)<<((shift))>>1)),shift)) This change fixed the
2006 Apr 20
5
Major internal changes, TI DSP build change
Hi Jim, > Build 11169 in SVN works correctly. Good. I'll try not to forget the EXTEND32 from now on. > I have attached a zip file (renamed > .txt) with a patch to bits.c to make the byteswapping for TI DSPs > consistent. Seems like unzip can't read it. Either it's in an unknown format or the file got corrupted. Could simply send as multiple (uncompressed)
2008 Jan 23
0
Shift count warning messages
I looked back at my old C55 EC build, and I had the same warning in mdf.c which Mike found. The assembly code did have a valid shift, and this build did cancel echo. When I built with the SVN head, I saw the errors in kiss_fft.c also. The assembly there also has valid shifts. So, I suspect that these warnings do not indicate a real problem. It might be interesting to break down the
2006 May 09
2
Speex echo canceller on TI C55 DSP
> I built and ran the same test on the TI C64 simulator, and the echo was > canceled nicely (about 10:1 reduction in the peak amplitude during the > second of two brief speech bursts). So, my problem must again be related to > the 16-bit processing on the C5X DSPs. Good. At least we've narrowed it down a bit. > Also, the line where it is hanging is: >
2006 Jul 24
2
Fix for lsp.c for 16-bit platforms (TI C55x DSP)
Jean-Marc, Last week I tried the SVN code (build 11700) on the TI C55x DSP, and found that operation was broken again. I traced this to build 11522, committed on 5 June. The problem is in lsp.c, function lsp_to_lpc(). The line (lsp.c line 461 in build 11700): xin = 1<<(QIMP-1); /* 0.5 in QIMP format */ evaluates to zero. The following change corrects the problem: xin =
2006 Nov 15
1
Re: 5. Re: how to build libspeex_armce.lib ? (patrick andrieux)
Hi Dave, I tried defining ARM5E_ASM and ARM4_AS, and you are right, it doesn't compile, But I can't say if the problem come from the Microsoft compiler, because if it doesn't know ARM assembly optimizations, who can know ? We may need to include/install something else to use ARM5E_ASM or ARM4_ASM, or maybe this part of speex's code is not finished. I tried to compare both
2005 May 25
3
Speex on TI C6x, Problem with TI C5x Patch
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.
2008 Feb 19
4
Patch for Analog Devices compiler & fixed-point AGC
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