similar to: Shoehorning speex is confusing a newbie

Mike, Generally "Invalid mode encounterd" == "frames are misaligned" You should be getting 20 bytes from the encoder each time, and passing 20 bytes to the decoder each time. Is it correct that you have modeled your main loop after testenc-TI-c5x.c? If you look at encoded silence with a binary editor, you should be able to see the 20-byte repetition pattern. You can also

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

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

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

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.

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

Somewhere in the new packet-loss concealment code, there is a bug. I tried encoding a 44100-hz stereo file and it decodes just fine, but if I try it with packet loss, I get a segmentation fault. If you want to see the file, I can put it up somewhere publicly accessible. If someone here can't work on it, I'll be back on my home computer in a few days, so I'll work on it then.

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

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++) >> { > ...

I tried to compress 160 samples of random garbage (range 0-500.f) at 4kbps and got a crash in nb_encode -> forced_pitch_quant because start was -858993460 (== ol_pitch). -- Daniel, Epic Games Inc. --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'speex-dev-request@xiph.org'

This patch will export new speex functions in the generated library, such as speex_encode_int as well as the preprocessor, echo-cancellation and jitterbuffers. The ordinals used matches the 1.1.6 release from the speex.org website, so any new library created with this def file should be binary compatible with that one. -------------- next part -------------- Index: speex.def

> Use speex_mode_query with SPEEX_SUBMODE_BITS_PER_FRAME > You need to pass the submode number with the pointer and the number of > bits per frame is returned using the same pointer. Note that with > speex_mode_query, the first argument is the mode (e.g. &speex_nb_mode), > not the encoder/decoder state. Thank you Jean-Marc, This works well. Now a followup question. Is there