similar to: Speech coding survey

Le mer 26/02/2003 à 15:43, Rick Kane a écrit : > 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. I've got a few samples at: http://www.speex.org/audio/samples/ Jean-Marc > > -----Original Message----- > > From: owner-speex-dev@xiph.org [mailto:owner-speex-dev@xiph.org]On

Hello Jean-Marc >If you want to do it, I can show you >what functions (there are 2-3) to port. Otherwise I might do it >eventually, but it's not a top priority (there's already an SSE version >though). I would indeed like to know which functions can be used to improve K6-2 performance through 3DNow. Cheers Bjoern D. Rasmussen <p><p><p>>From: Jean-Marc

What sould be the capture and playback buffer size in 8,16,32 khz for the Alsa system? Can this also causing latency? In the server side I have: -A thread that reads the input from mic (capture) ands copies to main buffer. -The main loop encodes and sends it to the client ( it's read the data from the main buffer) Client: -A thread for

This works really well for white noise reduction. However what I've noticed was the amplitudes of normal speech samples also get reduced. Is this something by design, or is there a way to automatically recover the original speech sample volumes ? <p>Thanks. <p>Tongbiao <p>-----Original Message----- From: Jean-Marc Valin [mailto:jean-marc.valin@hermes.usherb.ca] Sent:

I tried feeding in the 3 encoded frame in ONE BLOCK, and calling speex_decode() 3 times in a roll. Only the 1st frames came out perfectly. For the other 2, I got "corrupt" frame warning. I was supposed to get 38 bytes consumed each frame (narrow-band, VBR off). I tried speex_bits_remaining() to peek on the # of bits consumed, and got variable (clearly wrong)#s returned. But if I

Ohh... Nice! This is new in 1.0.1, isn't it? It doesn't seem to be included in the reference manual yet, though. Thanks! Tom <p>Jean-Marc Valin (jean-marc.valin@hermes.usherb.ca) wrote: > > OK, this is how it works: > > The encoder calls speex_encode any number of times and then calls > speex_bits_insert_terminator before sending the bits. > > The

Hi, I uploaded a pre-release of beta3 for which I'd like to get feedback. There are some new features like a new "ultra-wideband" mode for 32 kHz operation (up to 48 kHz) and a (intensity) stereo mode. You can get the source at: http://www.speex.org/download/Speex-1.0beta3cvs.tar.gz So please test that code and report any bug or inconsistency you may find. Jean-Marc --

It seems to work ok with the same audible quality as a standard sampling rate. Is there any way to test this? Will superimposing an inverse wave over the origional produce a meaningfull result? Thanks for your time, Ryan de Leeuw <p><p>>Sorry for the delay. I've been doing a couple tests >and what I'd suggest >is encoding using the narrowband (8 kHz normally)

> What is the maximum frame-length that libspeex will produce for narrow, > wide and ultrawide encoding? In normal operation (no in-band side information, like requests, ack, stereo, ...), the max size for a frame is 62 bytes in narrowband, 106 bytes for wideband and 110 bytes for ultra-wideband. Jean-Marc -- Jean-Marc Valin, M.Sc.A. LABORIUS (http://www.gel.usherb.ca/laborius)

Le dim 31/08/2003 à 20:12, Daniel Vogel a écrit : > > This works really well for white noise reduction. However > > what I've noticed was the amplitudes of normal speech samples > > also get reduced. > > Noticed this as well recently. This is probably due to the AGC (Adaptive Gain Control) that's integrated with the denoiser. I'll try adding an option to

Le lun 10/11/2003 à 11:19, Massimo a écrit : > On Sun, 2003-11-09 at 21:00, Jean-Marc Valin wrote: > On recent x86 processors, floating point is faster than fixed-point. > > Jean-Marc > > This left me something shocked. Please, can you tell me what kind of > processors are showing this behaviour? Are you referring to speex > codec

Hi everyone, I've just released version 1.1.4. This includes some code cleanup and improvements to the fixed-point port and SSE optimizations. All the SSE code has been converted to intrinsics and some new functions have been implemented with SSE. Overall, the speed has been increased by up to ~30% with SSE. Jean-Marc -- Jean-Marc Valin, M.Sc.A., ing. jr. LABORIUS

On Tue, 2003-04-15 at 11:31, Jean-Marc Valin wrote: > > How do i detect whether there is silence in media using speex? > > Is there any API which decides that the audio data only contains > > silence? > > Basically i will have PCM linear data, I want to know whether it is > > complete silence. > > Well, the best way is probably to turn VAD *and*

> Am I right with the assumption, that currently you have to enable > processor specific optimizations with compile/configure options? > > How difficult would it be to add support for runtime CPU detection? > Is this a feature you might consider adding? Pretty complicated because of some annoying decisions taken by the gcc team. The problem is that gcc won't let you use

Hi, just to let you know that unstable version 1.1.1 is out. It includes the latest fixed-point changes which can be enabled with --enable-fixed-point (as configure option) or -DENABLE_FIXED_POINT (for win32). The port is not complete, but most of the floating-point operations have been converted. Please give it a try and report any difference with previous versions (both for float and

> I had a similar question ... is the endian-ness of the encoded > speex file, system dependent? or is it always little endian? If it's > always little endian (like the header seems to be) then big endian > machines (or java) will need to map everything to bigendian before > decoding ... Well, wav's are considered little endian but for raw files, there's a

At 07:55 PM 3/11/03, Jean-Marc Valin wrote: > > - Only narrowband (8 kHz) Speex is currently supported; not > > wideband. (Unfortunately, the assumption that audio sample rate == 8 kHz > > is riddled throughout the Asterisk code.) > >Perhaps it's still possible to send wideband, while telling Asterisk >it's narrowband (the bit-stream is such that you can decode

> Yes, i have been using speex in my VoIP gateway product. There are > hundreds of threads that simultaneously call various speex APIs and > execute without any problem. But ofcourse, I use a speex encoder/decoder > vars on per stream basis. Its been tested successfully on Linux/Win2k. Actually, I just realized I fixed a potential minor thread problem recently. It's in 1.1.1

Maybe this is plain stupid or off topic. Could an atleast working fixed-point implementation of Speex be made by using a C++ "faked float" class with overloaded operators? Don't know if this is a common way to solve stuff like this, but my guess is that it would work. //Best Regards, Jonas Tärnström. <p>> > So just how much work are we talking about, here, to convert

Hi, Now that Speex is getting pretty stable, I have decided to make a fixed-point/integer port the #1 priority. At this point, I'm looking for help from people with prior fixed-point experience and/or a good signal processing background. Anyone would like to volunteer? I have already started the port by converting to int some of the most used functions. While this should only have a small