similar to: Re-encoding decoded Speex

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

Jean-Marc and others, We are using Speex inside our Video Conferencing application and have some questions about the trade-off of complexity vs bitrate. A little background information is needed: 1. For us the actual bit-rate isn't that big a deal. Speex running at 14kbps or 8 kbps is minor compared to the video traffic running at 128, 256 or 384 kbps. 2. We care a little about

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

Jean Marc, So assuming the quality setting was set as high as possible, and the audio stream was 8000 hz, 16 bit mono, I have two follow up questions: 1. Does the complexity setting override the quality setting, or does increasing the complexity only lower the rate at a given quality? Or would setting both higher increase the quality more? 2. What sort of impact would setting quality as high as

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

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:

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

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

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)

Hello The st->zeta pointer isn't freed in the speex_preprocess_state_destroy() function of the preprocess.c file (alloced in line 167). It's in Speex 1.1.4 by the way. I'm trying to make the denoiser work with my application and has got reasonable noise reduction after applying the denoiser. I, however, haven't been able to find any information of what the purpose of

So we ran the code on a Windows XP based Atholon XP system and the xmm registers work just fine so it appears that Windows 2000 and below does not support them. We agree on not supporting the non-FP version, however the run time flags need to be settable with a non FP SSE mode so that exceptions are avoided. I thus propose a set of defines like this instead of the ones in our initial patch:

Hi all, <p>i have send a mail to the jabber mailing list and ask them how to send speex data with the jabber instant messaging protocol. I have added the mail adter this one. If someone here has any experience with jabber and speex please let me know. Thanks, <p><p>Carsten Breuer ====================================================== Hi all, im new on this list, so i want to

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

re: At 03:22 PM 10/25/2005, Jean-Marc Valin wrote: >Are you really sure you didn't have some corruption elsewhere? Totally possible- this is the first time this has happened that I know of in many many hours of usage- On the other hand, this null check isn't in my code base and it was in nb_decode_lost, and nb_encode- so I figured it was just an oversight- Tom

At 12:35 PM 10/6/2004, Matthias Granberry wrote: >There is some SSE assembly >language, but it's in GCC/AT&T syntax rather than the windows-standard >Intel syntax, so you might have to do some of your own translation to >something your compiler understands. We submitted an intel patch a ways back- maybe it is in the archives somewhere... Tom -- Tom Harper -

Le mar 18/11/2003 à 17:39, Allen Drennan a écrit : > Speaking of video conferencing in conjunction with Speex, we are > currently beta testing a solution we developed that offers multi-point, > multi-party video and audio using the Speex engine for voice. > > http://www.wiredred.com/downloads/ecsetup.exe > > The fair and good audio settings are Speex narrowband, high quality

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