similar to: Preserving echo canceller state between two connections?

Hi Bernhard, Can you confirm I'm understanding everything correctly? You encode with the same encoder and then decode with either A) blackfin assembly and fixed-point or B) fixed-point only on Blackfin. Then A) sounds bad and B) sounds good. If you do the same in narrowband, it sounds OK. Is that correct? If that's the case, it's *probably* some kind of bug and/or invalid assumption

Hi everyone, I've just released Speex 1.1.9. The main change in this release is the echo canceller work sponsored by Tipic Inc (http://www.tipic.com/). It is now possible to do acoustic echo cancellation and obtain good attenuation after a short adaptation time. This has been tested at 8 kHz, but it should also work at 16 khz and above, so give it a try. There were also some fixes to the

Hi All, We are using speex for linphone in blackfin fixed point platform. The speex version we are using is svn-14525. If we don't disable vbr by "--disable-vbr", the sound quality will be very bad in linphone. But if we disable it, sound will be perfect. I noticed in the speex.org, there is a comment like this: > >Speex 1.2beta3 is out >December 11, 2007 >The most

> - Only narrowband (8 kHz) Speex is currently supported; not > wideband. (Unfortunately, the assumption that audio sample rate == 8 kHz > is riddled throughout the Asterisk code.) Perhaps it's still possible to send wideband, while telling Asterisk it's narrowband (the bit-stream is such that you can decode a wideband frame even if you think it's narrowband). > - Some

Hi Jean-Marc, > Can you confirm I'm understanding everything correctly? You encode > with > the same encoder and then decode with either A) blackfin assembly and > fixed-point or B) fixed-point only on Blackfin. Then A) sounds bad and > B) sounds good. If you do the same in narrowband, it sounds OK. Is > that > correct? If that's the case, it's *probably* some

nautiluz wrote: >I am starting project to develop open implementation of some (naturally open >codec) for simply designed embedded devices which can be used by small to >big VoIP operators or hobbyists which wants to build their own small and >low cost VoIP phone. >Speex seems to be great choice. And greater will be if there should be >some guys who want to help ;-). Sorry

Look at the manual. There's just too many possibilities to screw up I don't feel like listing them every time. With 8 kHz audio, 20 ms frames and 50-300 ms tail, I can definitely say that it works (as long as you get things right). Jean-Marc Le mercredi 21 d?cembre 2005 ? 13:51 +0800, wu xudong a ?crit : > I have tested the AEC by file model,but found it > doesn't work!The

Hello, I'm new on DSP and i want to implant speex echo canceller on the Blackfin DSK version of speex to work on the BF533 EZ-KIT LITE But i can perform the echo canceller to work This is my code, so if somebody can tell me where i'm wrong //----------------------------------------------------------------------------- // CallBackFunction() - Gets called by the audio pseudo-driver

FYI, the Asterisk software PBX <http://www.asterisk.org/> has now incorporated my recent patches to support dynamic RTP payload types. As a consequence, its SIP implementation now supports Speex, so if you have a Speex-compatible SIP client, you can use it to make calls using Asterisk. Some caveats: - Only narrowband (8 kHz) Speex is currently supported; not wideband. (Unfortunately,

On Mon, 21 Dec 2009 21:00:01 +0100, <speex-dev-request at xiph.org> wrote: > Thank you for your product Speex. We want to use it in > microcontroller AT91SAM7S256 (48 MHz). I'd strongly advice to use a higher performance micro. Let's consider that you'd succeed in getting it working right after optimizations. The time you want to add other speex features or other

Hi, I have been testing 1.2beta1 fixed point and non fixed point as well as 1.0.5 compiled agains uclibc and run on 150Mhz pentium MMX chip. 1.2 non fixed is fastest 60 seconds encoded in 32 seconds at quality 4 1.0.5 is second with the same file encoding in 39 seconds at quality 4 1.2 fixed is slowest with 60 seconds encoded in 58 seconds at quality 4 Is this as expected? Or am I doing

Hello all, I'm testing the Speex codec for my diploma thesis on a BF-533 Blackfin under uCLinux (2005R3 RC3 release). I successfully compiled the Speex (1.1.11-svn) and I can encode/decode wav-files on my STAMP-board using the speexenc/speexdec sample apps. But I encountered that the decoded file sounds strange/noisy, when compiling with "--enable-blackfin-asm" +

On Wed 18 Apr 2007 16:09, Jean-Marc Valin pondered: > > Speex has gone through alot of improvements since then, and I don't think > > the > > > > speex you have produces a binary compatible bitstream with the current > > trunk/release (if you are not looking for compatibility with other > > systems, it doesn't matter). > > Just a note here.

Jean-Marc, I recently started looking at running the echo canceller on a TI C55 DSP along with the 8kbps narrowband Speex encoder/decoder. This is one of those "braindead compilers" that you refer to from time to time, and cannot handle the float struct assignments in the return statements in pseudofloat.h. Most of these were eliminated in build 11311 (patch by Brian Retford), but

> So, I did following changes: > In every loop I remove %= (In Vis.DSP Help I didn't find such sign) > And loop become able to compile. Let me know if you think of something that would work in both gcc and VDSP. > With parallel issues I found several interesting things: > > 1) > "A0 -= R1.L*R0.H (IS), A1 -= R1.L*R0.L (M,IS) || R0 = [%1++];\n\t" >

Hi, I tried to figure out what the problem is -- but it seems to be totally different from what I expected. My status at the moment is: - computing results for "generic" and "Blackfin ASM" versions of the DIV32_16 function are the same, there is no "algorithmic bug" - Instead, there seems some sort of memory corruption: When I comment out the DIV32_16 function

Speex 1.2beta1 announcement: This new release brings many significant improvements. The quality has been improved, both at the encoder level and the decoder level. These include enhancer improvements (now on by default), input/output high-pass filters, as well as fixing minor regressions in previous 1.1.x releases. A strange and rare instability problem with pure sinusoids has also been fixed. On

Frank Lorenz a ?crit : > And yes, the same "overflow" happens even when I disable Blackfin ASM > optimizations. Indeed, that shouldn't happen. Just to make sure I understand, so far there's two problems: 1) DIV32_16() in Blackfin assembly causes problems 2) The resampler overflows When you fix/workaround those two, is the encoder/decoder working correctly or are there

> I would like to test the echo cancel algorithm available in unstable version > 1.1.4. This echo canceller can be used with other codecs like G711? If by "used with other codecs", you mean that you can use the result as input to any codec you like, the answer is yes. > Somebody could send me some documentation or sample, or explain the next > functions: > >

Hi Jean-Marc, didn't get a reply to my last post (see below) -- do you have no idea what happens here? After some more tests, I disabled the DIV32_16 Blackfin optimizations and now get good quality on the Blackfin. But when I have overdrive on the input, things become very bad -- I'm not sure if this is really a filter stability issue like I wrote some weeks ago. I use the speex