similar to: [PATCH] Add speex_preprocess_state_reset call

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

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

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

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

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

I wish Speex could come with instructions on how to build libspeex_armce.lib. ________________________________ From: speex-dev-bounces@xiph.org on behalf of speex-dev-request@xiph.org Sent: Mon 11/13/2006 3:01 PM To: speex-dev@xiph.org Subject: Speex-dev Digest, Vol 30, Issue 15 Send Speex-dev mailing list submissions to speex-dev@xiph.org To subscribe or unsubscribe via the World

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

Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: kissfftr_exit2.diff Type: application/octet-stream Size: 429 bytes Desc: kissfftr_exit2.diff Url : http://lists.xiph.org/pipermail/speex-dev/attachments/20061109/183092f6/kissfftr_exit2.obj

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

I had a quick look at the patch. Could the problem just be that you don't backup the eax/ebx/... registers and then the compiler expects that whatever value was there before the asm is still there? Le mer 22/10/2003 à 16:55, Aron Rosenberg a écrit : > 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

Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: preproc_patch_dth_10_26_05.patch Type: application/octet-stream Size: 8774 bytes Desc: not available Url : http://lists.xiph.org/pipermail/speex-dev/attachments/20051026/c27a3ed6/preproc_patch_dth_10_26_05.obj

Jean Marc, et al. Attached is a patch adding the Win32 Assembly needed for the SSE optimizations. It is against speex-1.0.2. We have implemented the patch as two new files, filters_sse_win32.h and ltp_sse_win32.h. In addition, there are modifications in filters.c and ltp.c adding a new ifdef called _USE_SSE_WIN32. The patch is fully functional and sees marked improvement in CPU usage

Wade, We have already done Altivec support for most of Speex. The patch is waiting on Jean-Marc adding the RunTime / Compile Time options so it doesn't crash systems that don't support Altivec such as G3's or early G4's. Aron Rosenberg SightSpeed www.sightspeed.com <p>At 09:20 PM 3/29/2004, Wade Williams wrote: >On Mar 29, 2004, at 5:05 PM, Jean-Marc Valin

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:

Actually, I prefer having the user explicitly specify --enable-sse because you might want to compile for other machines than what you have. Also, any idea what happens if the user already has CFLAGS=-O2 defined (and you add -O3)? Last thing, how do you check whether gcc accepts -msse? Jean-Marc Le ven 02/04/2004 à 00:40, Aron Rosenberg a écrit : > Here is code to add to configure.in

Jean-Marc, There is a big difference between SSE and SSEFP. The SSEFP means that the CPU supports the xmm registers. All Intel chips with SSE support do, however no current 32 bit AMD chips support the XMM registers. They will support the SSE instructions but not those registers. You are right about the SSE2 not being used. The AMD Opterons are the first AMD CPU's which support

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

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

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)