similar to: speex_encode / speex_encode_int ... already sorry =)

On Sun, Apr 25, 2004 at 04:18:16PM +0200, crazylord wrote: > Hi, i know this question has already been asked, i've checked mailing > list logs but ... > I didn't figure out the solution for my question. > > I want to use basic functionnality of speex, only VAD, no pre/post > filter, even no VBR. But i *really* want to use less mem/cpu i can. > So in which format

I always think short is better over float, because most of the time we don't get float form data, from, e.g microphone / wav files <p>-----Original Message----- From: owner-speex-dev@xiph.org [mailto:owner-speex-dev@xiph.org] On Behalf Of Conrad Parker Sent: Monday, April 26, 2004 12:58 AM To: speex-dev@xiph.org Subject: Re: [speex-dev] speex_encode / speex_encode_int ... already sorry

On Mon, Apr 26, 2004 at 01:32:53AM +1000, Kenji Chan wrote: > I always think short is better over float, because most of the time we don't > get float form data, from, e.g microphone / wav files It really depends on your framework. Hardware generally uses integer samples, but a number of newer software systems use float. On modern host cpus it's just as fast and you don't

Hi, I'm using speex 1.1.10 and writing a program similar to sampleenc. I need to use the fixed point library as I'm eventually porting to ARM processor but I encountered a problem with speex_encode_int(), which I used in place of speex_encode(). I gave it a short instead of a float (manual says it takes a short for the audio - 2nd parameter) but the compiler says it could not convert the

On Mon, Apr 19, 2004 at 02:46:44AM -0400, Jean-Marc Valin wrote: > OK, I'll try to do *something* about it. It'll be either "support the > 1.0 ABI" or "make sure the link will break". While the former would be > nice, I'm not sure I want to really want to force 1.2 to have the same > ABI as 1.0.x. More on this when I have some time to think about it.

Assuming one prefers to use the speex_encode_int() and speex_decode_int() when available, but fallback to speex_encode() and speex_decode() if an older version if the lib is installed, how does one best make the determination? The only thing I can see to do is call speex_init_header() and look at the result. Even at compile time it seems one must compile a test app that outputs that data and then

I have (finally) posted my Speex wrapper classes. They are at: http://www.grandgent.com/spx/tgAudioCodec.zip I followed your recommendations and they worked fine with 1.1.0. However, I'm still having the same problem with 1.1.7 that I had the last time I tried to upgrade. I'm using the same code with both versions, except for calling speex_encode_int instead of speex_encode, and

On Wed, Nov 17, 2004 at 09:05:05AM +0900, Jean-Marc Valin wrote: > Why do you want your app to with with 1.1.4 in the first place. It's a > old unstable version and its API has been changed since then. > ie. Flavio, please upgrade to the recent 1.1.6 release. In your code, you will need to change the follwing line (for the 1.1.x build only): > > /* Encode the frame */

Thank you for such a quick response. The only reason I started with Char buffers is because WaveIn and WaveOut on Windows XP accept/emit WAVEHDR structures, which store audio data in LPSTR, which is Char*. typedef struct { LPSTR lpData; DWORD dwBufferLength; ... } WAVEHDR; When I was going from Char to float and back looked very wrong to me as well, but I was just not

I'm confused about the format of the PCM/WAV data for speex_encode & speex_decode speex_encode(enc_state, input_frame, &bits); In the manual, it says "input_frame is a (float *) pointing to the beginning of a speech frame" (for encode) But I've found that in speexenc.c and testenc.c, short* is used instead of float* So, isn't it signed 16 bit samples(if

Alright noted, I changed me code so that the state is created in the constructor and destroyed in the destructor of the object. However I'm still getting the same issue although I'm sure that would have bit me sooner or later. The new code is as follows. virtual Enigma::u8* Encode(Enigma::u8* inputBuffer,size_t inputSize, size_t& outputSize) { short *in=(short*)inputBuffer;

Hi list ! I'm Patrick, a french student. i am developping a kind of softphone for pocket PC using speex. Sorry in advance for my bad english. Till now, i had good results, but now i've a problem with encoding. so to summarize, here is a short description of my work : I'm working on pocket pc I'm developing a GUI in C# I'm developing a dll in C++ which use speex

I'm having trouble with a Speex VOIP effort ... my first use of Speex. My development platform is Windows XP, but I intend to bring this up on OS X as well. At the moment, I send across speex frames (say 4 per packet... a configurable setting), and the settings of both encoder and decoder are simply fixed in code at the moment (wideband, short format input). I am fairly confident that I

Jean-Marc, Ok, I understand. It's floating point but I don't have a mechanism in place yet to capture the source data. I'll do that, reproduce the problem, and put together a minimal sample program that can reproduce it given a data file. Thanks, Tom Jean-Marc Valin <Jean-Marc.Valin@USherbrooke.ca> wrote: > > Hi Tom, > > In order to trace the problem,

Hi, I am writing a program that should be able to compile using speex version 1.0.1 and speex version 1.1.4, but a I am getting some trouble to encode with one version e decode using the other. The program is taking care of the change in both speex_encode and speex_decode. The sample being coded or decoded has changed from float to short. To test it, I have modified the sampleenc.c that

Hi, Guys I am starting looking the source code of Speex. Maybe a little silly, but I can not find the implementation of the function speex_encode(). Only something like below void speex_encode(void *state, float *in, SpeexBits *bits) { (*((SpeexMode**)state))->enc(state, in, bits); } Does that mean some of the detail implementation is embedded in lib without source code? I am new in

I'm only doing one frame using speex_encode_int greatly simplifies my code I'm not sure why the sample I was working off of was converting the shorts to floats then calling the other encode/decode methods. Based off of your suggestions I tried the following but I get the same result. virtual Enigma::u8* Encode(Enigma::u8* inputBuffer,size_t inputSize, size_t& outputSize) {

openh323 speexcodec.cxx has: BOOL SpeexCodec::EncodeFrame(BYTE * buffer, unsigned & length) { // convert PCM to float float floatData[SAMPLES_PER_FRAME]; PINDEX i; for (i = 0; i < SAMPLES_PER_FRAME; i++) floatData[i] = sampleBuffer[i]; // encode PCM data in sampleBuffer to buffer speex_bits_reset(bits); speex_encode(coder_state, floatData, bits);

Changing from using floats to shorts did fix the high pitched tone problem. I'm having other problems but I'll look into it more first. SteveK wrote: > > On May 21, 2006, at 6:33 PM, Kevin Jenkins wrote: > >> When I just copy the microphone input buffer to the output buffer the >> sound plays OK. But if I encode and decode the buffer through Speex I >>

Hi,I'm having performance issues encoding with speex on an iphone4 + iOS5. The same code yields excellent results on iPad2 + iOS5, Mac OS X 10.6 as well as Windows 7. The call to speex_encode_int is takes 0.0065 to complete. Because encoding is so latent the receiver incurs underruns. Here is my speex setup: ? ? unsigned val = 0; ? ? /**? ? ?* Initialize the encoder in narrow band mode.? ?