similar to: Shoehorning speex is confusing a newbie

Jean-Marc was correct in that the 16bit value was the culprit for my encoding woes. after I changed that to a 32 bit value I believe it encodes correctly, but I really don't have much of any way to know this absolutely. I am using the 1.2beta2. I would use the enctest program, I have looked it over and based a lot of what I am doing on that code but the project I am developing this on is

I thought I should be getting 20 words because in the windows app the command line repeats "nbBytes = 20" through the entire decode phase. I wonder how the frames got misaligned...right now I get 10 words of data followed by 10 words of 0's which I look at through a memory window in code composer. now I am pretty sure there is a terminator word that gets in there so that would make

This is going to take some explaining and I apologize in advance if any of this is found in the manual or sample code but I couldn't find it. I just graduated last may and this is my first experience with vocoders and dissecting a professional's code. I work for a company that is currently using a G729A vocoder from a 3rd party software company and is looking into speex so they no

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.

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 C5416, 16 bit, narrowband. The project I am implementing speex into is very limited in Data space. In the speex decode_init and encode_init there are allocs that, combined, take up 0x0F94 of data memory. I do not know why the various allocs are sized the way they are but that number is too big to fit into our project. I was wondering if those numbers (for

On Thu, 2003-04-17 at 07:48, Kaveh Goudarzi wrote: > Hi, > > I had a similar question ... is the endian-ness of the encoded > speex file, system dependent? or is it always little endian? If it's > always little endian (like the header seems to be) then big endian > machines (or java) will need to map everything to bigendian before > decoding ... > I have spent some

Dear Speex developers, I am currently experimenting with Speex on Symbian smartphones. I have compiled the Speex library, and I am now using it in the following way: 1. Record 320-byte buffers of data in PCM16 format, 8000 Hz sampling rate. 2. Feed the resulting buffer to an instance of a narrowband Speex encoder. 3. Send the encoded data over RTP. 4. Upon receiving on the other side, feed the

Hi, So I got a crash on the following code: k1=SUBMODE(lpc_enh_k1); k2=SUBMODE(lpc_enh_k2); which in the newer codebase is: bw_lpc(SUBMODE(lpc_enh_k1), st->interp_qlpc, awk1, st->lpcSize); bw_lpc(SUBMODE(lpc_enh_k2), st->interp_qlpc, awk2, st->lpcSize); I am not sure if the newer code will have the same issue but the following check is

Hello, I currently have speex "working" in my project but the encode and the decode don't seem to be working like I would hope. I am using speex 1.2beta2 and I am trying to 16bit 8kbs narrowband. on the decode side I encoded a voice on a windows machine. I took the encoded information and transferred it over to the C54x project and decoded it and it didn't sound that great.

This must have been an enormous pain to track down. The manual alloc routine in the TI directory (user_misc.h) clears the allocated memory, but maybe you have changed this. >> it will just start filling data in, which it shouldn't. I see that >> innov_save is set at the beginning of a for loop at: >> for (sub=0;sub<st->nbSubframes;sub++) >> { > ...

Hi list! There seem to be some oddities in using ABR. The first thing I notice is that because "abr_count" increases without bound, after a while the weight of the bitrate history will completely swamp any change in the current bitrate and the ABR adjustment will essentially stop happening. This seems to be true in any mode (not just UWB) and perhaps a solution is to cap

On Tue, Feb 25, 2020 at 05:45:06PM +0200, Ville Syrj?l? wrote: > On Tue, Feb 25, 2020 at 04:19:27PM +0100, Andrzej Hajda wrote: > > On 25.02.2020 12:21, Ville Syrj?l? wrote: > > > On Mon, Feb 24, 2020 at 03:14:54PM +0100, Andrzej Hajda wrote: > > >> On 19.02.2020 21:35, Ville Syrjala wrote: > > >>> From: Ville Syrj?l? <ville.syrjala at

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,

> -----Message d'origine----- > De : Jean-Marc Valin [mailto:jean-marc.valin at usherbrooke.ca] > Envoy? : dimanche, 14. juin 2009 20:46 > ? : Stephane Lesage > Cc : speex-dev at xiph.org > Objet : Re: [Speex-dev] Resampler saturation > > Just to make sure I understand, the two patches you sent are > two different ways to fix the problem, with the only >

> In particular, (I'm not really sure, because I don't thorougly > understand it yet) I don't think your jitterbuffer handles: > > DTX: discontinuous transmission. That is dealt with by the codec, at least for Speex. When it stops receiving packets, it already knows whether it's in DTX/CNG mode. > clock skew: (see discussion, though) Clock skew is one of the main

Hi, We'd like to announce the first draft for the Speex RTP profile. It was written essentially by Greg Herlein, with some help from Simon Morlat and I. We'd like to get some feedback on it before it is sent to the IETF. Basically this will allow all SIP based VoIP applications using Speex to inter-operate. For those interested, there's already Simon's LinPhone (www.linphone.org)

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

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