similar to: Integrating speex with VideoNet application: Constant background noise

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 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, I've changed the m_waveFormatEx.wBitsPerSample for both record buffer and playSound buffer, changed my array from char to short and I'm still getting the same constant background noise. I notice that when I talk into the mike, I will get a slightly louder noise, can't hear any clear speech... Any idea what's wrong? Regards, Carine ----- Original Message ---- From: John Miles

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, 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, 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:- > >

hi sirs, i am only recently studying speex and i'm looking for a C++ wrapper for speex that has higer-level implementations for the Encode and Decode functions, to sort of base my initial understaning of how the speex API work. i have in fact created my own, following on the instructions in the speex codec manual, but i havn't really made any positive progress. (a lot of people have

Ronald, I recently wrote some wrapper classes for the Speex encoder and decoder for use with my VoIP program. I think they're pretty high level and easy to use. They handle all buffer allocation internally to make life easy. Here's a simple little example that happens to use VAD: // buf is float[] or short int[], buflen is multiple of frame size // (there is a getFrameSize() method

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

Ronald, I suggest we take this discussion off the list after this post. I don't see any problems with your code. However, I can make a few suggestions: 1) If you replace the lines: pSpeexHdr->lpData = (char*)pSound; pSpeexHdr->dwBufferLength = decodedSamples * sizeof(short); with: pSpeexHdr->lpData = lpHdr->lpData; pSpeexHdr->dwBufferLength = lpHdr->dwBufferLength;

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

--- 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

hi Tom, i downloaded your speex wrappers and they're really what i'm looking for! i really cannot worry about container support at the moment because i'm working with real-time audio, and hopefully toward VoIP when everything else is in order. im using waveform to capture data from the microphone. the raw PCM sample is stored in the WAVEHDR structure's member lpData, and this

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) *