similar to: API changes for Speex 1.2

Hi, Speex is progressing and I've started thinking about the next 1.2 release (don't hold your breath). Though the bit-stream won't change, the API likely will. The API for 1.1.x already differs from 1.0.x because the speex_encode and speex_decode now use shorts instead of floats. Now, since I'm changing the API anyway, I thought I might as well fix things that might be annoying

Le ven 16/04/2004 à 16:39, Kenji Chan a écrit : > Ok, I'm using 1.1.4, so I should pass signed short(wav data) directly to > speex_encode()? First, I'd like to ak why you want to use 1.1.4. If you don't need the new features (fixed-point or preprocessor), you should probably stick to 1.0.3, which has received more testing. If you choose to use 1.1.4, you need to send shorts to

Hi, I think what happened is that you did not write the "message" length. With user-callbacks, you also need to say how large the message. The size is in bytes and encoded in 4 bits. Besides, you're probably the first one to use user-callbacks. BTW, why didn't you want to use Ogg. It's much simpler to use and overhead can be made minimal anyway. Jean-Marc Le ven

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. Suggestions are welcome. Jean-Marc Le lun 19/04/2004 à 02:18, Conrad Parker a

Well, you seem to be using FRAME_SIZE but only defining frame_size. Otherwise, the code looks OK, but it's always hard to tell. I suggest you start from speexenc/speexdec or from the example I wrote in the manual at: http://www.speex.org/manual/node12.html Jean-Marc Le ven 19/12/2003 à 05:22, Fabio a écrit : > Hi > i'm developing a sort of VoIP application > for my

Yes it's the minimum, as you can't decode half a frame. In Speex frames are 20ms which should be low enough anyway. Jean-Marc Le ven 16/05/2003 à 04:03, Robert M. a écrit : > Here is my situation: > > I have large Speex encoded stream which I would like to playback on wave > out device. I could decode whole stream to pcm and play it back as pcm > audio, but this

Note that FIXED_POINT is only related to compiling speex, not your application. Also, in 1.1.x, the output and output format for audio changed to 'short' (instead of float). Jean-Marc Le lun 19/01/2004 à 05:19, Rodrigo Parra M a écrit : > Hi all, > > Please a moment to look my source code, this is very similar to > example of the documentation. I added FIXED_POINT

> How do i detect whether there is silence in media using speex? > Is there any API which decides that the audio data only contains > silence? > Basically i will have PCM linear data, I want to know whether it is > complete silence. Well, the best way is probably to turn VAD *and* DTX on. Then when there's silence, the speex_encode function will return zero, which

I tried feeding in the 3 encoded frame in ONE BLOCK, and calling speex_decode() 3 times in a roll. Only the 1st frames came out perfectly. For the other 2, I got "corrupt" frame warning. I was supposed to get 38 bytes consumed each frame (narrow-band, VBR off). I tried speex_bits_remaining() to peek on the # of bits consumed, and got variable (clearly wrong)#s returned. But if I

> I just downloaded http://www.speex.org/download/speex-1.1.4.tar.gz and > tried to build it but the file denoise.c seems to be missing from the > archive. > Can you fix this or is it better to get everything from cvs? You're using Windows, right? The project file is simply out of date. The denoise.c file has been renamed to preprocess.c > Another question, when will a stable

> I'm about to try to integrate SPEEX into the VOCAL project. Good. Just a detail, but the correct spelling in "Speex". > 1) To encode, it appears I need an array of floats. If > I am playing wav files, what is the best way to turn these > into something speex can encode? Speex version 1.0.x (stable) expects float's in the -32768 to +32767 range, so it's just

> If I decode to .wav, it works fine. However, if I decode to .raw, it > does not work (the decoded file when viewed on GoldWave on Windows > appears to be all noise. I've tried 16-bit, signed, unsigned, big > endian and little endian, mono and stereo PCM - none make a difference > - the decoded file always appears to be noise). Can you try manually swapping the bytes on

Hi everyone, I've just released version 1.1.4. This includes some code cleanup and improvements to the fixed-point port and SSE optimizations. All the SSE code has been converted to intrinsics and some new functions have been implemented with SSE. Overall, the speed has been increased by up to ~30% with SSE. Jean-Marc -- Jean-Marc Valin, M.Sc.A., ing. jr. LABORIUS

Hi, Before I try to code this myself, I'd like to know if anyone has a fixed-point routine to compute the cos and acos functions. All I need is around 3-digit accuracy. Thanks. Jean-Marc -- Jean-Marc Valin, M.Sc.A., ing. jr. LABORIUS (http://www.gel.usherb.ca/laborius) Université de Sherbrooke, Québec, Canada -------------- next part -------------- A non-text attachment was

> 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 ... Well, wav's are considered little endian but for raw files, there's a

Ohh... Nice! This is new in 1.0.1, isn't it? It doesn't seem to be included in the reference manual yet, though. Thanks! Tom <p>Jean-Marc Valin (jean-marc.valin@hermes.usherb.ca) wrote: > > OK, this is how it works: > > The encoder calls speex_encode any number of times and then calls > speex_bits_insert_terminator before sending the bits. > > The

Le dim 31/08/2003 à 20:12, Daniel Vogel a écrit : > > This works really well for white noise reduction. However > > what I've noticed was the amplitudes of normal speech samples > > also get reduced. > > Noticed this as well recently. This is probably due to the AGC (Adaptive Gain Control) that's integrated with the denoiser. I'll try adding an option to

Le lun 10/11/2003 à 11:19, Massimo a écrit : > On Sun, 2003-11-09 at 21:00, Jean-Marc Valin wrote: > On recent x86 processors, floating point is faster than fixed-point. > > Jean-Marc > > This left me something shocked. Please, can you tell me what kind of > processors are showing this behaviour? Are you referring to speex > codec

> Am I right with the assumption, that currently you have to enable > processor specific optimizations with compile/configure options? > > How difficult would it be to add support for runtime CPU detection? > Is this a feature you might consider adding? Pretty complicated because of some annoying decisions taken by the gcc team. The problem is that gcc won't let you use

Hi, Now that Speex is getting pretty stable, I have decided to make a fixed-point/integer port the #1 priority. At this point, I'm looking for help from people with prior fixed-point experience and/or a good signal processing background. Anyone would like to volunteer? I have already started the port by converting to int some of the most used functions. While this should only have a small