similar to: RE 2. Quick survey for Speex 1.2 (Jean-Marc Valin)

If you want to test the AEC, I recommend using the svn version of Speex. Jean-Marc Aymeric Moizard a ?crit : > > I finally solved my problem: > > My **static** speex library is compiled with: > -D_LIB > > While I should compile it with: > -D_USRDLL > > I'm not able to understand completely why: anyway, it > now can be compiled without breaking anything.

I finally solved my problem: My **static** speex library is compiled with: -D_LIB While I should compile it with: -D_USRDLL I'm not able to understand completely why: anyway, it now can be compiled without breaking anything. I'll now test wether the aec have an impact or not :) tks, Aymeric MOIZARD / ANTISIP amsip - http://www.antisip.com osip2 - http://www.osip.org eXosip2 -

On Wed, 6 Dec 2006, lianghu xu wrote: > Hi Jean-Marc, > > I remember you said that the SDP tells the mode information. Right. But a decoder like speex can always be configured from information contained in the incoming stream. That makes your application more interroperable. Aymeric MOIZARD / ANTISIP amsip - http://www.antisip.com osip2 - http://www.osip.org eXosip2 -

I'm getting confused, what's the problem exactly? The AGC doesn't remove the DC or it adds one? Jean-Marc Aymeric Moizard a ?crit : > Hi Jean-Marc & all, > > I'm currently working on a wav file with very low volume. > This wav also contains a DC component. > > Using testdenoise with modification (AGC turned on with > 20000.0 value) I'm able to

In a "normal" frame that doesn't have in-band signalling (which nobody seems to use anyway), the frame starts with the narrowband information. If the frame is in wideband, then this will be followed by a bit of wideband information that starts with a bit set to 1 (narrowband starts with a bit set to 0). Have a look at what the Speex decoder does. You may actually want to have similar

On Fri, 27 Feb 2009, Jean-Marc Valin wrote: > Hi Aymeric, > > Yes, I'm receiving the emails but haven't had enough time to look into > the details yet. I've seen you responded to many comments, so what are > the ones for which we still need to respond? Summary is there: https://datatracker.ietf.org/idtracker/ballot/2837/ As I understand: we need to change

On Mon, 6 Nov 2006, Jean-Marc Valin wrote: > That's quite a strange problem. Considering that Speex doesn't have any > "init code" (stuff that executes when it's loaded), there's no way this > could be a bug in Speex. True. > I see two likely possibilities (plus lots of > unlikely): > 1) A bug in your code. Linking with Speex pushes your code to a

That's quite a strange problem. Considering that Speex doesn't have any "init code" (stuff that executes when it's loaded), there's no way this could be a bug in Speex. I see two likely possibilities (plus lots of unlikely): 1) A bug in your code. Linking with Speex pushes your code to a different place in memory and triggers the bug 2) A bug in Visual Studio. You can

Hi Jean-Marc, I remember you said that the SDP tells the mode information. Is SDP what you called in-band signalling? Lianghu On 12/6/06, Jean-Marc Valin <jean-marc.valin@usherbrooke.ca> wrote: > > In a "normal" frame that doesn't have in-band signalling (which nobody > seems to use anyway), the frame starts with the narrowband information. > If the frame is in

Following up on the original topic of synchronization between the local mic and local speaker streams: We can separate this problem into two sub-problems: (1) compensating for differences in sampling rates; and (2) compensating for delay between the two streams. For estimating the delay, what do you think of the idea of using cross-correlation? -mjc -----Original Message----- From: Jean-Marc

Hi Jean-Marc, Alfred and Greg, Are you receiving the mails from IETF about draft-ietf-avt-rtp-speex The mails are not coming from AVT mailing list, but I think we are all 3 part of a minimal list (draft-ietf-avt-rtp-speex at tools.ietf.org) dedicated to latest discussion about the draft. I have answered some questions, but there are small changes and adaptation still required to the ietf

Hi, I'm experiencing weird problems while testing speex (I want to test the echo canceller first) on PDA with WM5 version pocket PC 2005. Here is the strange scenario: 1-> App running without being linked with speex -> no problem 2-> App running while being linked with speex -> crash at always the same place. NO ACCESS TO

On Thu, 16 Oct 2008, Jean-Marc Valin wrote: > Aymeric Moizard a ?crit : >>> None of that is defined yet, though I'm open to suggestions on how to do >>> the mapping. >> >> CELT/44100 and CELT/48000 >> a=fmtp:105 stereo=on >> >> probably a latency value? > > It would definitely need a frame_size value > >> "CELT"

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

This paper is very interesting. Just to add my own opinion on this: My main problem concerning those elements is to synchronize different soundcard on different PC! The aec is working on both outgoing (mic) and incomnig (RTP) stream. The problem most show up with USB wich appear to have very different clock than "classic" soundcard hardware. In those cases, when you get let's say

On Thu, 2 Nov 2006, Jean-Marc Valin wrote: >> In those cases, when you get let's say 1000 packets of 20ms from the mic >> you may have only 990 packets of 20ms from RTP incoming stream. >> >> Thus, before sending outgoing mic/RTP stream, you would wait for 1000 >> incoming packets: where last packet in fact arrive 10*20ms = 200ms >> after it was supposed

Hi Jean-Marc and all, I was playing with the AGC with different sampling rate and I experienced smaller volume level when I increase the sample rate. Should I use a different value for AGC_LEVEL when using different sample rate? I'm using speex-1.2rc1.tar.gz Tks, Aymeric MOIZARD / ANTISIP amsip - http://www.antisip.com osip2 - http://www.osip.org eXosip2 -

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

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

It would be nice to merge the Run-Time SSE/Altivec patch that we have been maintaining. Aron Rosenberg SightSpeed Inc. -----Original Message----- From: speex-dev-bounces@xiph.org [mailto:speex-dev-bounces@xiph.org] On Behalf Of Jean-Marc Valin Sent: Monday, November 13, 2006 1:32 AM To: speex-dev Subject: [Speex-dev] Quick survey for Speex 1.2 Hi everyone, As you may have guess, Speex 1.2 is