similar to: Re: Library Split Poll

Hi everyone, In the 1.1.x branch, I've kept adding more stuff to libspeex: preprocessor, AEC, etc. I'm now considering moving all those to a separate library (libvoip, libspeech, whatever). Anyone on this list has good reasons I should consider for either splitting or not splitting libspeex? Cheers, Jean-Marc

I have sent the visual studio project files that compile the speex client to jean-marc directly (as an attachment), sometime this week, I will also upload the binary builds of static library files to my site www.phonestack.com. I am porting our LTP (lightweight telephony protocol) to some embedded systems. I require to run speex in an environment that doesn't support memory allocations. How

On Wed, 2006-06-28 at 11:34 +0530, Ashhar Farhan wrote: > I have sent the visual studio project files that compile the speex > client to jean-marc directly (as an attachment), sometime this week, I > will also upload the binary builds of static library files to my site > www.phonestack.com. Actually, Zen (illi on IRC) is the one handling the Windows stuff. I can't do anything with

From: Thorvald Natvig <slicer at users.sourceforge.net> Some optimizing compilers miscompile the current SSE optimizations when full optimizations are enabled. By using output value pointer instead of a return value, we can bypass this misbehaviour. --- libspeex/resample.c | 8 ++++---- libspeex/resample_sse.h | 24 ++++++++---------------- 2 files changed, 12 insertions(+), 20

Spam detection software, running on the system "mix.hive.no", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: I recently found a .. weird bug on Win32 SSE with GCC

Duane Storey a ?crit : > Actually, it might just be an OS "feature".. On most linux and mac > platforms, the memory managers align memory on proper boundaries -- this > doesn't occur on most versions of windows. I don't have all the code in > front of me, but it's possible that it's simply a side effect of windows not > aligning the memory, and an

From: Jyri Sarha <jsarha at ti.com> Semantics of inner_product_single have also been changed to contain the final right shift and saturation so it can also be implemented in the optimal way for the used platform. This change affects fixed point calculations only. I also added a new fixed point macro SATURATE32PSHR(x, shift, a). It does pretty much the same thing as SATURATE32(PSHR32(x,

On 5/29/08, Thorvald Natvig <thorvald at natvig.com> wrote: > Alexander Chemeris wrote: > > On 5/29/08, Thorvald Natvig <thorvald at natvig.com> wrote: > > > I've done listening tests when converting wb_male.wav to 44.1, 48 and 8khz, > > > and there aren't any obvious artifacts. I also did a 16=>16 test, and the > > > results are delayed

Actually, it might just be an OS "feature".. On most linux and mac platforms, the memory managers align memory on proper boundaries -- this doesn't occur on most versions of windows. I don't have all the code in front of me, but it's possible that it's simply a side effect of windows not aligning the memory, and an implicit assumption in the speex code that it will have

Hi, I made a small error in the impulse reponse function; when doing the inverse fft in fixed point, it will overflow unless it's properly scaled. This patch uses the same scaling as that used when updating the filters, and the outputs now have the same shape and the same scale in fixed and floating point. Best regards, Thorvald -------------- next part -------------- diff -ubBwr

Hi, The attached patch fixes an incistency in my earlier patch. Whereas the rest of the AGC ctls are in dB, GET_AGC_GAIN was linear. This patch fixes that. It also changes the API for _GET and _SET_AGC_LEVEL to use a int32 instead of a float, meaning we don't need to do a API change when we get a fixed point AGC. Best regards, Thorvald -------------- next part -------------- ---

Alexander Chemeris wrote: > Hi, > > On 5/27/08, Thorvald Natvig <thorvald at natvig.com> wrote: > >> And here's a patch for Intel Math Kernel Library. This allows commercial >> users of Speex to use a high-speed FFT library that isn't GPL'd. (You do >> need to pay for it though). This is 3 times faster than the default FFT in >> speex, and

Hi, Here are some questions from user point of view. :) On 5/29/08, Thorvald Natvig <thorvald at natvig.com> wrote: > I've done listening tests when converting wb_male.wav to 44.1, 48 and 8khz, > and there aren't any obvious artifacts. I also did a 16=>16 test, and the > results are delayed by 10ms and within +/- 1 (basically, rounding errors > from the FFT). Do

On 5/29/08, Thorvald Natvig <thorvald at natvig.com> wrote: > > > Yes, I plan to use it in a VoIP environment if I can get latency reduced to > > > an acceptable level :) > > > The latency depends directly on the overlap parameter, which also controls > > > the quality. Higher quality => higher latency. You could set the overlap to > > > 0,

Alexander Chemeris wrote: > Hi, > > Here are some questions from user point of view. :) > > On 5/29/08, Thorvald Natvig <thorvald at natvig.com> wrote: > >> I've done listening tests when converting wb_male.wav to 44.1, 48 and 8khz, >> and there aren't any obvious artifacts. I also did a 16=>16 test, and the >> results are delayed by 10ms

Thorvald, re: At 03:18 AM 1/6/2006, Thorvald Natvig wrote: >I just checked it in the debugger, and this was with gcc 3.4.4 (mingw)... >And the addresses were not properly aligned :( From a bit of googling, >this seems to be a thread problem, as the gcc just maintains 16-byte >alignment of the stack -- if the start function of the thread had >misaligned stack, the misalignment

Tom, Thorvald, Could one of you submit the details to the gcc bugzilla so it gets fixed? BTW, is 4.0 affected? Jean-Marc Le vendredi 06 janvier 2006 ? 17:13 -0800, Tom Harper a ?crit : > Thorvald, > > re: > At 03:18 AM 1/6/2006, Thorvald Natvig wrote: > >I just checked it in the debugger, and this was with gcc 3.4.4 (mingw)... > >And the addresses were not properly

Hi everyone, Judging from the lack of complaints about the split, I think I can go safely forward with that. The only thing to decide is the name of the new library that will contain the preprocessor, the AEC, jitter buffer, and resampler. So far, I've got a few potential names: - libspeaks - libspeexproc - libspeexvoip - libspeech - libspoke Let me know (in private so as to not flood the

Jean-Marc Valin wrote: > Thorvald Natvig a ?crit : > >> I see you're changing the jitter buffer around quite a bit. Could you >> let us know when it's ready for general testing? (At the moment it >> doesn't handle missing packets at all) >> > > While I'm not completely done yet, I thought the current version was > working. Can you tell

It seems that speex jitter buffer is tightly coupled with SPEEX codec [we have to give a speex decoder instance to JB]. It would be better if we could use it with any codec, like speex preprocessor and AEC. What are the any paper/theory/algorithms behind current ADAPTIVENESS of speex JB? Links to those algo/papers would help to understand better. -- Shantanu --- Thorvald Natvig