similar to: Improving memory allocation

Hi, I'm currently working on improving the allocation of temporary data to allow allocation directly on the (real) stack instead of my pseudo-stack. I'll probably leave the old allocator available as an option for compilers that don't understand variable-size arrays, but I'd like to have an idea of how many people it affects. Are there many people who cannot compile the following

> I don't think visual c++ 6.0, .Net or any other msft compiler in existence > will handle this properly. Msft has pushed off C99 support indefinitely, > from what I understand. Also didn't work on the intel compiler last > time I checked (v. 8.1). Can you check in case there's at least a compiler switch to allow it on those compilers? > In order to make things work

Hi everyone, As many noticed, I just released 1.0.5 and 1.1.8 over the weekend. There isn't much new in 1.0.5, except that I added all the API changes from 1.1.x so that it's possible to write code that will work with both 1.0.5 and 1.1.8. As for 1.1.8, here are the changes: - Initial TI C5x port: I integrated a patch from Jamey Hicks - Some fixed-point improvements and fixes - Better

> Ok, what you suggest sound logical to me. Currently, I > have done a small trick to prevent this problem. What > I did is that whenever windows request a voice packet > from me and if I do not have the voice packet, I > repeat the previous packet. Hence, all the breaking > portion is filled with previous packet. This trick > seems to work so far. I am not sure what is the

If you have a couple minutes, it probably wouldn't be hard to see where the bug is (I just don't have time this week). It would have to do with the granulepos computation in speexenc. Jean-Marc Le jeudi 07 juillet 2005 ? 08:41 +0300, David Resnick a ?crit : > Thank you very much for your immediate attention! > > I've exported my wav files to raw files before encoding and

Sorry, the 3rd party and (AFAIK) windows builds are still 1.1.6. I have no idea what compiler was used. Of course ARM4_ASM was not used, since the option didn't exist in 1.1.6. Jean-Marc Le samedi 05 mars 2005 ? 13:04 +0100, Fabio a ?crit : > Hi all, > Are the 3rd party builds in page > http://www.speex.org/download.html > based on Speex 1.1.7 ? > > Thanks > Fabio

Le jeudi 13 janvier 2005 ? 10:59 -0500, Jared Whitby a ?crit : > Interestingly enough.. I started playing around with preprocessing > options in 1.1.6 and happened upon the denoise filter > (SPEEX_PREPROCESS_SET_DENOISE). When i run the test tone using that > option it is completely filtered out and I just get (complete) > silence. When the test tone is intermixed with regular voice

Hi, I tried the same options suggested in your post and the problem continues. What do you suggest? 2005/9/15, Jean-Marc Valin <Jean-Marc.Valin@usherbrooke.ca>: > Hi Eduardo, > > All I can say is that the timings you have are a bit odd. What > optimizations options are you using (I suggest -O3)? Also, perhaps you > can try --enable-arm4-asm just in case. I've had the

Good question. I'm coming to the conclusion that using plain UDP and "home-grown" packet construction for transmitting the speex data (with timestamp/sequence counter) and implementing jitter control on the receiver end is an adequate implementation for a VoIP application. Assuming of course that I don't care about any interoperability issues with other applications etc. I was

Hi, I not really keeping track of the revision numbers for releases. As for the tags, 1.1.8 is at http://svn.xiph.org/tags/speex-1-1-8/ and 1.0.5 is at http://svn.xiph.org/tags/speex-1-0-5 For older releases, the tags are sometimes just rel-x-y-y because that's what I was doing before the switch to svn (the tree was imported from cvs). Oh, and the 1.0 branch is in

I realize that hearing tests are far superior for calibrating codec internals, particularly the perceptual enhancement. The tester is for finding gross mistakes like overflows. The test program includes code to subsample the 32Khz source down to 8 and 18 Khz. I've broadend the tests to try all the possibilities like VBR, perceptual enhancement, complexity and quality. The results are

What platform (OS, compiler/version) Also, does it work with no options. Jean-Marc Le jeudi 12 mai 2005 ? 08:49 +0200, Pierre a ?crit : > Pierre wrote: > > Jean-Marc Valin wrote: > > > >> OK, first thing I see is the configure options: > >> > >> ./configure --enable-valgrind --enable-sse --enable-fixed-point > >> --enable-epic-48k

Le jeudi 24 mars 2005 ? 10:08 +0000, John Villar a ?crit : > Jean-Marc, that's not the definition of OpenSource, that's the > definition of "Free Software" (Libre!=Gratis) Open-Source and Free Software are basically doing the same thing for different reasons. If something isn't free software, it's not open-source either. There may be exceptions, but I have yet to

Hi, To increase the stack size, you can increase the value in the speex_alloc() call in nb_celp.c. Let me know if it solves the problem. Also, what compiler are you using. I think some older versions of gcc may have problems with SSE intrinsics. Jean-Marc Le mardi 19 avril 2005 ? 16:02 +0200, jehan Monnier a ?crit : > Hi, > > I also tried to build speex 1.1.7 with sse enabled on a

Le jeudi 22 septembre 2005 ? 08:19 +0800, Joe Anny a ?crit : > Thanks, Jean for the clarification. My first name's Jean-Marc, not Jean... > I look forward to delving into your tutorial codes. What we hope is to use > Speex as the primary voice codec. We also hope to get a quick start into > the programming aspects with buffer management, denoising, etc. taken care > of (or

The patch is still valid, though it may require minor adjustments. Although support could be improved (optimizations, codebook packing), the patch should at least allow Speex to run on a C55. Jean-Marc Le mercredi 02 mars 2005 ? 15:00 -0600, Paul Gryting a ?crit : > I saw a thread in the list archives about a speex port to TI 55x DSP. > Wondering how that worked out (is working out)?

Thank you very much for your immediate attention! I've exported my wav files to raw files before encoding and the click is now gone. That sure beats discarding the last packet, which was the workaround "solution" I was going to implement... Best regards, David Resnick -----Original Message----- From: Jean-Marc Valin [mailto:Jean-Marc.Valin@USherbrooke.ca] Sent: Thursday, July 07,

hi, jean-marc: i think we can remove spx_sig_t *orig. but am not sure about exc2Buf. is it for extension? rgds, tk On Mon, 28 Feb 2005 12:42:38 -0500, Jean-Marc Valin <Jean-Marc.Valin@usherbrooke.ca> wrote: > Hi, > > I looked at the code I think there are still places where you can reduce > memory. For example, I think bufSize can be reduced to around 400 > (instead of

Hi, Just to let you know version 1.1.6 is out. Changes are: * Improved jitter buffer (now actually works!) * Denoiser tuning * Improved echo canceller (please send feedback) * Support for Symbian OS (thanks to Conrad Parker) * Gapless playback for speexenc/speexdec * Run-time identification of Speex version with a new speex_lib_ctl() call * Moved the includes to /usr/include/speex/ Jean-Marc

Le jeudi 30 d?cembre 2004 ? 21:35 +0100, Alfredo Moreira a ?crit : > I'm going to test the echo cancellation... > but before doing something wrong, i want to know what is the right way > to use it... The best I can suggest is to *not* use it... unless you know how to debug/tune it. Jean-Marc >