similar to: [PATCH] missing speexdec directory for vs2008, modes_wb.c

I pulled the test directory from 2003, but everything else from 2005. The 2005 files have more ?cross-compiling? targets than the 2003 ones. I fixed the various missing files in the new 2008 projects (misc.c and one other other are gone now). The only thing you could do which would make them more compact would be to get rid of the subdirectories under each vs-version. There is no real need for

Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: speex_vs2008.diff Type: application/octet-stream Size: 165590 bytes Desc: speex_vs2008.diff Url : http://lists.xiph.org/pipermail/speex-dev/attachments/20071127/08917736/speex_vs2008-0001.obj

Ok! If there are indeed cross-compiling targets defined, then vs2005 projects probably should be maintained. In any case, this is all up to Jean-Marc, since he's the one that actually has authority to change it :) Jean-Marc -- what's your opinion? On 11/28/07, Aron Rosenberg <arosenberg@sightspeed.com> wrote: > > I pulled the test directory from 2003, but everything else

We just came across an occasional crash with the Win32 Assembly patch I sent in earlier, so hold off on applying it until we send an updated version. Aron Rosenberg SightSpeed http://www.sightspeed.com <p>--- >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

Here is code to add to configure.in to do what you want. It preserves CFLAGS and uses that var to hold the sse enable flags. You can subset this under the exisiting AC_ARG for sse or just make it do it all the time. If you notice the i?86, that means any x86 platform target will have it enabled. You can change that i686, but keep in mind that some distros compile/target for i386 on the glibc

The VS2005 project files are known to not be up-to-date, so I can understand that you'd need to fix some things. Can you verify with an import of the VS2003 project files, that there is no need for any fixes, and just works after importing? Managing multiple project files should be minimized if at all possible. If a straight import of vs2003 project files can be done without any changes

In speex_alloc.h The following code #ifdef USE_ALLOCA #include <alloca.h> #endif should be: #ifdef USE_ALLOCA #ifdef WIN32 #include <malloc.h> #else #include <alloca.h> #endif #endif for visual studio at least. Not sure about mingw Aron Rosenberg www.sightspeed.com

Greetings, <p>my apologies for putting this trash in the mailing list but the topic about SSE run-time option interested me pretty much. Looks like some people is really experienced on the topic. I would really appreciate if somebody could point me to good resources about SSE and Altivec (not necessarly on the net, I'm ready to invest some money if necessary). I already have intel

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

Jean-Marc, Are you sure that you don't need to add just -msse to enable the intrinsics rather than a full fledged -march=pentium3? I did some playing around and I can get intrinsics code to compile with -march=i686 -msse on linux with that. Check out:

All, Attached is a patch that does two things. First it makes the use of the current SSE code a run time option through the use of speex_decoder_ctl() and speex_encoder_ctl It does this twofold. First there is a modification to the configure.in script which introduces a check based upon platform. It will compile in the sse assembly if you are on an i?86 based platform by making a

On Mar 29, 2004, at 5:05 PM, Jean-Marc Valin wrote: > Can you try manually swapping the bytes on the raw output and see if > you > get something useful (I think by default wav is always little endian > while raw is native endian)? Well, my apologies. Apparently I got confused when trying all the different formats and somehow skipped little endian. The decoded raw file is in

> Is it a problem if all the files are compiled with -march=pentium3 > ? The patch that we sent in already detects in the configure.in script > which system you are on and sets a define correctly, i.e. _USE_SSE. Well, if what you want is auto-detection, turning on -march=pentium3 means that the code will crash on anything lower than a pentium3. Not really useful. Of course,

Jean-Marc, Good catch on the debug mode. After compiling the same code in release mode it does appear to be using all the registers correctly. Give us a few days to integrate our run-time flags into 1.1.4 and I will let you know how are testing turns out. Aron Rosenberg SightSpeed At 08:54 PM 1/21/2004, you wrote: > > 1. Compile Error with regular mode (FIXED_POINT undefined)

Hi everyone, I'm currently attempting to move Speex development over to Git. Because Git is distributed, I means that anyone would be able to do development and commits without having to get write access (and I can just pull from them). There are of course other advantages, like sane handling of branches and tags, local history, ... Now, one of the disadvantages is that Git currently

Not a big deal, but the "<http://xiph.org/svn.html>Subversion Access" link on http://www.speex.org/download.html page should probably point to: http://www.xiph.org/svn/ rather than: http://xiph.org/svn.html Tom ______________________________________________ Tom Harper Lead Software Engineer SightSpeed - <http://www.sightspeed.com/>http://www.sightspeed.com/ 918 Parker

Congrats Jean Marc, Just heard you got a new google assistant for the Ghost project! Tom ______________________________________________ Tom Harper Lead Software Engineer SightSpeed - <http://www.sightspeed.com/>http://www.sightspeed.com/ 918 Parker St, Suite A14 Berkeley, CA 94710 Email: tharper@sightspeed.com Phone: 510-665-2920 Fax: 510-649-9569 My SightSpeed Video Link:

Jean-Marc, So I saw in the latest code that the vad in the preprocessor is gone/going to be re-written. Is there a plan as far as this goes? Just wondering as the current one seems to work pretty well. Thanks! Tom ______________________________________________ Tom Harper Lead Software Engineer SightSpeed - <http://www.sightspeed.com/>http://www.sightspeed.com/ 918 Parker St, Suite A14

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

> 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