similar to: Speex 1.1.3 is out

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

> 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

> 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

> Yes, i have been using speex in my VoIP gateway product. There are > hundreds of threads that simultaneously call various speex APIs and > execute without any problem. But ofcourse, I use a speex encoder/decoder > vars on per stream basis. Its been tested successfully on Linux/Win2k. Actually, I just realized I fixed a potential minor thread problem recently. It's in 1.1.1

Hi, just to let you know that unstable version 1.1.1 is out. It includes the latest fixed-point changes which can be enabled with --enable-fixed-point (as configure option) or -DENABLE_FIXED_POINT (for win32). The port is not complete, but most of the floating-point operations have been converted. Please give it a try and report any difference with previous versions (both for float and

> > OK, so here's a first start. I've translated to intrinsics the asm I > > sent 1-2 days ago. The result is about 5% slower than the pure asm > > approach, so it's not too bad (SSE asm is 2x faster than x87). Note that > > unlike the previous version which had a kludge to work with order 8 > > (required for wideband), this version only works with order

Hi, I have been doing some work on a fixed-point port and it is now in CVS. All of the CPU-intensive parts should now be using only integer operations. Now, it's in a state where even non-coders can help: find bugs. With all these changes, there are probably several bugs and some may show up only under specific circumstances. Please test to see if the fixed-point behaves the same as 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

Le mer 17/12/2003 à 14:14, Greg Cockroft a écrit : > Target is Spv & Nokia phones ARM and also ipaq ARM. What frequency is the ARM processor? > With the generic fixed point at complexity 0 I am still about 1.6x realtime > for narrowband. > > The MS eVC compiler does not support inline assembler, only separate > assembler functions. > > Does anyone have a feeling on

> If you have any luck getting the eVC compiler closer to realtime I'd really > like to know. I'm still far from realtime when using Speex 1.1.3 on a HP > iPAQ (Intel pxa255). That's odd. I've been able to do real-time with about 20% CPU on an ARM 400 MHz. Here are the settings I used: - Compiled with FIXED_POINT (--enable-fixed-point) and ARM_ASM (--enable-arm-asm) -

Le dim 09/11/2003 à 14:33, Steve Kann a écrit : > Just out of curiosity, has anyone profiled the difference between the > floating point and fixed point implementations on processors with > decent floating point support? (i.e. x86, PPC). On recent x86 processors, floating point is faster than fixed-point. Jean-Marc -- Jean-Marc Valin, M.Sc.A., ing. jr. LABORIUS

Le jeu 15/01/2004 à 15:30, Daniel Vogel a écrit : > Unrelated, but please use SSE/MMX/... intrinsics on Windows instead of using > inline assembly so you also get the speed benefit on Win64. OK, so here's a first start. I've translated to intrinsics the asm I sent 1-2 days ago. The result is about 5% slower than the pure asm approach, so it's not too bad (SSE asm is 2x faster

> 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

> What I did to find this out: > I comprared a speex AVB with 6.3 KBit/sec (total, overhead for packets and > stuff included) and the 6.3 Kbit/sec Celp Codec vom hawkvoice ( > http://www.hawksoft.com/hawkvoice) and the result is quite favorable for > hawkvoice. > I cant believe that this is *normal* speex behavior, please correct me if that > hawkvoice thing just performs

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

OK, what happens is that I try to allocate one big chunk of memory, so that no other allocation is needed in run-time. The biggest part of that memory is used for a custom stack I use everywhere because C doesn't allow variable-length stack arrays. The sizes I used will work for all configurations (any mode/bit-rate/complexity), but if you're only interested in a subset, you can probably

Thanks for the fix. I applied to CVS. It'll be included in the 1.0.1 version I plan to release soon. Jean-Marc Le sam 31/05/2003 à 18:10, Anders S. Johansen a écrit : > Hi! > > Speexdec "clips" playback of files on fast Windows machines when > invoking it in decode-and-play mode by only supplying a filename for the > source file - the end of the sound

Oops... You've just found a bug. Seems like you're the first one to use that call. Anyway, it's now fixed in CVS (both trunk and 1.0.x branch). Thanks for the bug report. Jean-Marc Le mar 03/06/2003 à 01:16, Christian Buchner a écrit : > Hi there. > > I am having a little trouble understanding the frame sizes chosen > by the codec. > > testenc_uwb.c from