similar to: Attempting to shrink speex: Are these functions necessary?

Hi, I am using speex 1.2beta2 on a narrowband 16-bit, 8khz system that has a severe program space problem and will not fit speex in its normal operation. In an attempt to shrink speex I placed a breakpoint in every function and ran a decode and encode and removed the breakpoints that I hit. in the functions that had a breakpoint that I didn't hit I commented out those functions (as well as

I'm glad to hear that my data size can be shrunk considerably, however I do not know the minimum values that I would set the static arrays to be. I hate to be a bother but could you tell me the minimum values for these arrays/structures in the state structure? Thanks! encode: stack winBuf excBuf swBuf lagWindow old_lsp old_qlsp mem_sp mem_sw mem_sw_whole mem_exc mem_exc2 pi_gain pitch

Thank you, I really appreciate the help. -Mike >>> Jean-Marc Valin <jean-marc.valin@usherbrooke.ca> 08/07/07 8:34 AM >>> Michael Jacobson a ?crit : > I'm glad to hear that my data size can be shrunk considerably, > however I do not know the minimum values that I would set the static > arrays to be. I hate to be a bother but could you tell me the >

Hi, I've attached a patch against SVN r14645 which adds GCC visibility information to all symbols exported from libspeex.so and libspeexdsp.so. It includes a configure.ac change to test that both the compiler flags and __attribute__((visibility)) works, and if so will #define EXPORT __attribute__((visibility("default"))) and if not #define EXPORT I've attached a diff output

Hi, I've attached a patch against SVN r14645 which adds GCC visibility information to all symbols exported from libspeex.so and libspeexdsp.so. It includes a configure.ac change to test that both the compiler flags and __attribute__((visibility)) works, and if so will #define EXPORT __attribute__((visibility("default"))) and if not #define EXPORT I've attached a diff output

This patch will export new speex functions in the generated library, such as speex_encode_int as well as the preprocessor, echo-cancellation and jitterbuffers. The ordinals used matches the 1.1.6 release from the speex.org website, so any new library created with this def file should be binary compatible with that one. -------------- next part -------------- Index: speex.def

Hi everyone, I?m a graduate student in a Brazilian Intitute of Technology, and I?m doing some academic research regarding secure voice transmission over phone lines. One of our reserach goals is to implement a hardware vocoder, with low bit rates, and a preferably free algorithm, to be used in this secure voice system. Actually, there is a functional system using a proprietary AMBE

Hi, My name is Jean Quirion and I am a DSP engineer. Currently I am working on a project where it is desired to implement a VoIP solution over a GSM GPRS link. I would like to use Speex as the vocoder for this application. This application would require the Speex encoder/decoder and possibly the pre-processor to run on a low power fixed-point DSP such as a TI C55x. Thus, I am interested in

Hello, I'm interested in a low rate vocoder to run on SA-1110 or XScale processor (for PDAs voice application). Is there a suitable speex vocoder for that? Thanks in advance, Eyal. ________________________________________________ Get your own "800" number Voicemail, fax, email, and a lot more http://www.ureach.com/reg/tag --- >8 ---- List archives:

-This is my 'sip.conf' file: ;************************************************************* ; ; SIP Configuration for Asterisk ; [general] port = 5060 ; Port to bind to bindaddr = 0.0.0.0 ; Address to bind to context = default ; Default for incoming calls tos=184 maxexpirey=3600 ; Max length of incoming registration we allow

I was wondering if the developers were using anything to "objectively" test the quality of the speex vocoder. For instance PSQM or one of the many derivatives. Mean Opinion Scoring seems an expensive route. Is there some open source software to use for this? <p>--- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To

Jim, Thank you very much for your suggestions. I managed to get the C55x code working on the simulator. I would like to port Speex both on a C5502 EVM and a C5509A EVM. As such, if you can provide me with the details of your port on the C5509A, it would be greatly appreciated. Furthermore, I am looking for some technical documentation on the CELP algorithms. I would like to better

I was also wondering if there is a standard set of input sequences people are using to test Speex. I haven't stumbled upon it/them yet. > -----Original Message----- > From: owner-speex-dev@xiph.org [mailto:owner-speex-dev@xiph.org]On > Behalf Of Jean-Marc Valin > Sent: Tuesday, February 25, 2003 7:24 PM > To: speex > Subject: Re: [speex-dev] Quality > > > > I

Hi, I found this message concerning VAD and was wondering whether VAD has been ported to fixed-point in the latest version? Thanks, SingHui ---------- Forwarded message ---------- From: Jean-Marc Valin <Jean-Marc.Valin@usherbrooke.ca> Date: Jul 22, 2005 1:02 AM Subject: Re: [Speex-dev] Fixed-point To: gue baja <gue_baja@yahoo.com> Cc: speex-dev@xiph.org Hi Baja, Here's a quick

-----Original Message----- From: Jean-Marc Valin [mailto:jean-marc.valin@usherbrooke.ca] Sent: Thursday, June 14, 2007 11:17 PM To: Michael Shatz Cc: speex-dev@xiph.org Subject: Re: [Speex-dev] Blackfin inline assembler and VisualDSP++ toolchain Michael Shatz a ?crit : >>> Actually, you're the first I know using the VisualDSP++ toolchain >>> :-) >> >> I guess

I just got a grandstream SIP phone Here is my sip.conf for the phone [mlh] type=friend insecure=yes username=mlh secret=mlh host=dynamic canreinvite=no The phone as the default config on it. If I use the phone to call a Zap interface (a tdm card) the voice sounds all choppy. If I use the phone to call a x100p card, it does not dial what I dial (no DTMF) I don't know

I've noticed that the nb decoder uses floating point in several places even when using FIXED_POINT. I don't have to deal with lost packets, so I'm mainly interested in innov_gain and pgain in no transmission mode (nb_celp.c around line 1272) and g and exci in vocoder mode (around line 1557). Is there a reason that these places must use floating point, or would it be possible to

I'm trying to get ChansSpy to work. It works, in the pass/fail sense, but it is difficult to understand the various speakers. I can hear users on our end just fine, but the other end sounds like their going through a vocoder, if I can understand them at all. Otherwise it is just garbled. We are using the following setup: all of our phones are SIP phones; for our outgoing calls we make use of a

Is there any place where I can see a summary of what is being done and what is still pending with the fixed point version of the libraries? I have some experience with vocoders and fairly good experience with de-jitters and suchs. I may be able to help. Thanks Baja

-----Original Message----- From: Jean-Marc Valin [mailto:jean-marc.valin@usherbrooke.ca] Sent: Tuesday, June 19, 2007 6:38 PM To: Michael Shatz Cc: speex-dev@xiph.org Subject: Re: [Speex-dev] Blackfin inline assembler and VisualDSP++ toolchain >> Yes, data footprint in the new version is quite manageable. Still I would >> wish better documentation for speex_alloc_scratch(). >