similar to: Newbie - Encoding PCM

Hi, i'm following encoder example in the manual.pdf of speex documentation. Here's my portion of code: int SPEEX_EncodePCM(struct _IDA_ClientSocket *IDA,char *buffer,unsigned char *PCM,int num_samples) { int ret,c,d=0,nbBytes,ttBytes=0; float PCM_F[160]; char cBits[200]; #ifndef DISABLESPEEX speex_bits_reset(&IDA->speex_bits); for(c=0;c<num_samples;c++) {

Hi, i'm following encoder example in the manual.pdf of speex documentation. Here's my portion of code: int SPEEX_EncodePCM(struct _IDA_ClientSocket *IDA,char *buffer,unsigned char *PCM,int num_samples) { int ret,c,d=0,nbBytes,ttBytes=0; float PCM_F[160]; char cBits[200]; #ifndef DISABLESPEEX speex_bits_reset(&IDA->speex_bits); for(c=0;c<num_samples;c++) {

As for me - speex_echo_cancellation is a better choise. Try using it in capture thread instead of those speex_echo_capture and speex_echo_playback functions. And please, describe your problem in details. Cause the fact that you "didn get echo cancellation" doesn't mean you are doing smth wrong. Regards, Anton A. Shpakovsky -----Original Message----- From: speex-dev-bounces at

Hi, what is the good way to encode / decode multiple frames in packet ? I read that I must do multiple call to encode and thats it. But when I'm trying to decode,, it doesn't work. Maybe, the problem is my decode function. Here is my encode function void ms_speex_enc_process(MSSpeexEnc *obj) { .... Do I need to increase gran value to 640 or read / encode (2 times)

Anton A. Shpakovsky <saa <at> tomsksoft.com> writes: > > As for me - speex_echo_cancellation is a better choise. Try using it in > capture thread instead > of those speex_echo_capture and speex_echo_playback functions. > > And please, describe your problem in details. Cause the fact that you > "didn get echo cancellation" > doesn't mean you are

Well, I'm not a professional in AEC theory, but what I've mentioned is: speex_echo_state_init(20, 320*10) - frame size should correspond to 20ms. At your sampling rate (16000hz) is should be 16K*0.02 = 320. The same I can notice about echo tail. 100ms: 16000*0.3 = 4800, not 3200 as you has. But that's not crucial I think. Just wanna you get the point. "Internally,

Jean-Marc, The following patch makes the above two read functions const correct. Cheers, Erik diff --git a/include/speex/speex_bits.h b/include/speex/speex_bits.h index a26fb4c..234ec53 100644 --- a/include/speex/speex_bits.h +++ b/include/speex/speex_bits.h @@ -77,7 +77,7 @@ void speex_bits_reset(SpeexBits *bits); void speex_bits_rewind(SpeexBits *bits); /** Initializes the bit-stream

Dear R Users, Any insights into why the following occurs would be helpful.... Firstly: #Evaluating proportions p<-as.list(rep(0,times=length(n))) #creating object of appropriate size. for(j in 1:length(n)){ for(k in 1:length(n[[j]])){ p[[j]][[k]]<- (s[[j]][[k]]/n[[j]][k])}} # 31 x k x num_samples(dim) where k varies The list object s[[j]][[k]] has 3 levels, j, k, and i. j represents the

An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/speex-dev/attachments/20091029/e587399d/attachment.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: tmezo.vcf Type: text/x-vcard Size: 345 bytes Desc: not available Url : http://lists.xiph.org/pipermail/speex-dev/attachments/20091029/e587399d/attachment.vcf

hi, this patch should fix the symbian build. /alfred -------------- next part -------------- A non-text attachment was scrubbed... Name: speex-symbian2.patch Type: text/x-patch Size: 2669 bytes Desc: not available Url : http://lists.xiph.org/pipermail/speex-dev/attachments/20061115/5ac4915e/speex-symbian2.bin

The replay gain code has dos line endings in CVS, which causes problems for the Sun compiler, among others. Attached is a patch for the lazy, but it's probably easier to fix locally and commit. -r

On Sat, Jun 04, 2005 at 08:00:45AM -0700, Ralph Giles wrote: > The replay gain code has dos line endings in CVS, which causes problems > for the Sun compiler, among others. Attached is a patch for the lazy, > but it's probably easier to fix locally and commit. Now with actual patch... -r -------------- next part -------------- Index:

Hi jere, thanks for this link, i'll see if i can do something good with that. speex.dll : ----------- I have a speex.dll which work, and i can encode and decode a wav file. (i used male.wav on speex.org for my test). But my dll is specific to my softphone. In fact i just include speex.h and i call speex functions for [en;de]coding. My code is based on speex website's sample :

Hi there. I made a couple of noted regarding the speex API. These are not meant be seen as critisism - rather constructive suggestions. I like speex a lot, but I would like it even more if some of the following features were available. ;) Christian <p>Comments about the Speex API - from a developer's perspective ------------------------------------------------------------- ***

thumbnailer/swfdec-thumbnailer.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) New commits: commit a31d0686b78df2da96b9d8d1e3220e63978bba30 Author: Benjamin Otte <otte at gnome.org> Date: Wed Nov 7 20:02:04 2007 +0100 s/swfdec_player_get_image_size/swfdec_player_get_default_size/ diff --git a/thumbnailer/swfdec-thumbnailer.c b/thumbnailer/swfdec-thumbnailer.c index

hi Jean-Marc, I just updated from svn and it looks like there are some errors in the speex.mmp file. the filters.c is duplicated, and the fft/kiss.c files are still missing.. /alfred Jean-Marc Valin wrote: > Applied in svn. Thanks. > > Jean-Marc > > Alfred E. Heggestad a ?crit : >> hi, >> >> this patch should fix the symbian build. >> >> >>

Hi Marian, I took a brief look at RFC 5574 and as far as I understand, you can simply do it like this: SpeexBits b; speex_encode(state, some320bytePCM1, &b); speex_encode(state, some320bytePCM2, &b); After that, get the encoded data with speex_bits_write and put it in your packet. Mark -----Original Message----- From: speex-dev-bounces at xiph.org [mailto:speex-dev-bounces at

I saw a thread in the list archives about a speex port to TI 55x DSP. Wondering how that worked out (is working out)? Also wondering if there is a source archive for it, or if the patch in the email archives is still current, or if there's been updates. Any info appreciated. Thanks Paul

>> Oh, your table looked fine. I think it's mine that was wrong for the >> "null mode" (which nobody ever uses I guess!). > > I'm not sure, but I guess it may be used in VBR or DTX mode? > At least that's why I kept it. Of course it *can* be used (and needs fixing). It just seems few people did :-) > So, what's the next step towards

This portion of the RFC is gramatically incorrect and confusing: The RTP payload MUST be padded to provide an integer number of octets as the payload length. These padding bits MUST be all zero. This padding is only required for the last frame in the packet, and only to ensure the packet contents ends on an octet boundary. <p> -- Ben Greear <greearb@candelatech.com>