similar to: Integrating speex with VideoNet application: Constantbackground noise

Hi, I'm still unable to get rid of the background noise though I've changed the PCM samples to 16 bit. I'm began to wonder if I can just take the PCM samples and encode them. What my application tries to do is to record the voice from a microphone, encode it, send it via the socket to a peer, decode at the peer's side and play the voice. My application works fine without the

Hi John, Thanks for your reply. Yes, my output device is in 8-bit mode, same as my input mode. I'm actually working in char (8 bit) arrays. Is it necessary to work in signed short integers only? I changed all the short arrays in the example to char. Carine ----- Original Message ---- From: John Miles <jmiles@pop.net> To: carineliang@yahoo.com.sg; speex-dev@xiph.org Sent: Thursday,

Hi John, I noticed the values after decode is very much different from the values of the original PCM samples. For cases when the PCM sample values are constant (because no one is speaking), the decoded values fluctuate too. These fluatuations are causing the background noise. Is my observation expected? Thanks, Carine ----- Original Message ---- From: John Miles <jmiles@pop.net> To:

The absolute values may be different for a variety of reasons; you can hardwire them all to 0 to see if your noise goes away. Make sure the values on the decompressed (PCM) side are little-endian (low byte first in memory), assuming you're working in Windows on x86. -- john RAD Game Tools -----Original Message----- From: Carine Liang [mailto:carineliang@yahoo.com.sg] Sent: Sunday,

Hi, Can someone please help me with my problem below. Any suggestions is appreciated. thanks, Carine ----- Original Message ---- From: Carine Liang <carineliang@yahoo.com.sg> To: speex-dev@xiph.org; speex-dev@xiph.org Sent: Tuesday, 31 October 2006 1:05:49 PM Subject: [Speex-dev] Integrating speex with VideoNet application: Constant background noise Hi, I am developing a peer-to-peer

Hi Jean-Marc, I finally make it work! Thanks for telling me that the algo will not work for 8-bit PCM. In fact I've tried using 16 bit PCM last time, but apparently there's a bug. The bug lies with the RecBuffer. The RecBuffer must be set to 320bytes instead of 160 bytes since every sample is now 16 bit. The compression is amazing, from 320 bytes to 38bytes! Thanks a million, Carine

Hi Jean-Marc, Thanks. I've got the code for sampleenc and sampledec. But I didn't know how to verify whether the decoded file is correct. So I tried to analyse the decoded output and compile with my input. Test case: PCM samples, 8 bit, 8000 samples per sec. When I pulled all my input to 0s, after encode and decode, the output fluctuates around -0.12 to 0.2 (in float), so when finally

Hi, I am developing a peer-to-peer video conference application which uses speex as a codec for the voice. I am new to speex, so please bear with me if I asked the obvious. After I added the encode and decode function to my MFC app, I heard a constant background noise, even when no one is speaking into the microphone. #define FRAME_SIZE 160 The application is coded in MFC C++. The record

Hi, I am using the speex 1.0.4 library from Windows. I have posted my problem before but didn't get a solution. I am doing an VOIP project in which i am recording sound and streaming it to the peer. I wanted to encode and decode wav files that brought me to this site. I am recording sound in the following format:- m_WaveFormatEx.wFormatTag = WAVE_FORMAT_PCM;

Vinod Vijayan wrote: >Hi, > I am using the speex 1.0.4 library from Windows. > I have posted my problem before but didn't get a solution. I am doing an >VOIP project > in which i am recording sound and streaming it to the peer. I wanted to >encode and decode > wav files that brought me to this site. > > I am recording sound in the following format:- > >

hello everybody in this great mailing list , i have some difficulties to follow my code . i solved some problems thanks to Carine Liang , but i still have one problem and i think it is fatal one. when i encode the voice data in a wav file it is decoded without any errors it gives me 84 bytes wav file size for 139 kbytes wav audio data .Naturally i wanted to return my file back to its normal

Dear Peter, I am running your g.test() with the william's correction but I have a question about the input numbers. These are my data: "Our data are consistent with those obtained using microarray comparative genome hybridization in that we found significantly fewer variants per Mb on the X compared to the autosomal chromosomes (152 versus 336 respectively, G = 93.4, P < 2e-16, df =

--- src/libFLAC/bitreader.c | 445 +++++++++++------------------------------------ 1 files changed, 105 insertions(+), 340 deletions(-) diff --git a/src/libFLAC/bitreader.c b/src/libFLAC/bitreader.c index ae515a0..7ae086d 100644 --- a/src/libFLAC/bitreader.c +++ b/src/libFLAC/bitreader.c @@ -755,379 +755,144 @@ FLAC__bool FLAC__bitreader_read_rice_signed(FLAC__BitReader *br, int *val, unsig }

On Fri, Mar 14, 2008 at 07:36:31PM +0100, Miroslav Lichvar wrote: > attached are patches that improve decoding speed a bit. The first > patch improves the bit scan macro used for decoding unary values, the > second one adds a GCC inline assembly for bswap and the third patch > replaces the read_rice_block function. The third patch has a bug causing reading past input buffer, attaching

Hi, attached are patches that improve decoding speed a bit. The first patch improves the bit scan macro used for decoding unary values, the second one adds a GCC inline assembly for bswap and the third patch replaces the read_rice_block function. In my testing it turned out to be even faster than the _ia32_bswap function. If the code produced by MSVC is faster as well, I'd suggest to remove

Hello, I'm having trouble connecting to an Apple Time Capsule's smb shares. The connection doesn't work, and with "dmesg" I see the following message, repeated every time I try: [26937.531511] CIFS VFS: RFC1001 size 39 bigger than SMB for Mid=4 [26937.531580] Bad SMB: : dump of 48 bytes of data at 0xffff880052832380 [26937.531615] 00000027 424d53ff 00000074 00018800

Josh Coalson <xflac@yahoo.com> wrote: > thanks for the patch. No prob :) > also, if you have miroslav's patch again a more updated version > of bitbuffer.c that would be great. I have been meaning to get > around to applying it for a long time. This is Miroslav's patch, from the mailing list post I dug up in the archives: --- orig/src/libFLAC/bitbuffer.c +++

Ok, here is a patch waiting for new CVS :). It works fine for me, but please check it before commiting... -- Miroslav Lichvar -------------- next part -------------- --- src/libFLAC/bitbuffer.c.orig 2003-01-30 17:36:01.000000000 +0100 +++ src/libFLAC/bitbuffer.c 2003-01-30 21:53:18.000000000 +0100 @@ -51,6 +51,25 @@ */ static const unsigned FLAC__BITBUFFER_DEFAULT_CAPACITY = ((65536 - 64) *

A friend of mine recently had a problem with a "broken" .WAV file (as you call them) because oggenc first printed out a warning and then didn't accept the file because of a "unexpected EOF error". Because I was interested in the issue, I decided to take a look at the oggenc source, and in fact, it is your .WAV reader that's wrong. More precisely: there are two version

I'm only doing one frame using speex_encode_int greatly simplifies my code I'm not sure why the sample I was working off of was converting the shorts to floats then calling the other encode/decode methods. Based off of your suggestions I tried the following but I get the same result. virtual Enigma::u8* Encode(Enigma::u8* inputBuffer,size_t inputSize, size_t& outputSize) {