similar to: A case indicating VAD bug

if the new draft in the manual is used. I don't find how to tell the decoder which mode(NB/WB/UWB) is used in the encoder. The RTP header don't contain the mode field and I don't find the mode information in the coded frame either. Does this mean we have to use NB decoder in all cases? Lianghu On 11/22/06, Jean-Marc Valin <jean-marc.valin@usherbrooke.ca> wrote: > >

Hi Marc, Thanks for your quick response. So if VAD is enabled then VBR will be enable although it's a special VBR. How about take out the VAD code from the VBR and remove the code else? Lianghu On 10/24/06, Jean-Marc Valin <jean-marc.valin@usherbrooke.ca> wrote: > > > 1) there are VAD related codes in the source file preprocess.c. > > Will VAD still work If I

In a word, I don't what's the standard of speex payload format. The file doc/rtp.txt is for what? Is it not for rtp payload? I find that rtp.txt is more detail that draft02.txt Which rtp docment should be followed? Anyone else has written the RTP wrapper already? Lianghu On 11/22/06, Jean-Marc Valin <jean-marc.valin@usherbrooke.ca> wrote: > > > 1) First, I think there is

In a "normal" frame that doesn't have in-band signalling (which nobody seems to use anyway), the frame starts with the narrowband information. If the frame is in wideband, then this will be followed by a bit of wideband information that starts with a bit set to 1 (narrowband starts with a bit set to 0). Have a look at what the Speex decoder does. You may actually want to have similar

On Wed, 6 Dec 2006, lianghu xu wrote: > Hi Jean-Marc, > > I remember you said that the SDP tells the mode information. Right. But a decoder like speex can always be configured from information contained in the incoming stream. That makes your application more interroperable. Aymeric MOIZARD / ANTISIP amsip - http://www.antisip.com osip2 - http://www.osip.org eXosip2 -

Hi Jean-Marc and All, Two things need your confirmation/suggestion. 1) First, I think there is a bug in libspeex/lsp.c line 512. /* hard limit ak's to +/- 32767 */ if (a < -32767) a =32767; // This line should be changed to if (a < -32767) a = -32767; if (a > 32767) a = 32767; ak[j-1] = (short)a; 2) About the RTP wrapper for VoIP I'd like to use the

Hello, I'm try to run speex on some ARM processor. I'd like to cut away some speex features including VBR, ABR and preprocessor while still supporting VAD/DTX. But I've found some puzzles in the source code regarding VAD as below, 1) there are VAD related codes in the source file preprocess.c. Will VAD still work If I don't use the source file preprocess.c? 2)The speex manual

> Another issue is the memory allocations distributed so many places that > it's hard to provide a single memory initial function interface. > > In a VoIP case on ARM, the total memory size for speex codec should be > known at the inital stage since all the memories are allocated > at the initial stage. If you want everything in the same big block, all you need to do is

> The mode/bit-rate is detected automatically by the decoder because it's > encoded in the first few bits of each frame. The encoder can change > bit-rate at any time without telling the decoder. Can you be more > precise as to what isn't clear? I think that one got me too. If mode is detected automatically by the decoder, what is the purpose of the 'mode' parameter

Hi, We are using LLVM 2.9 (with the llvm-gcc front end) to compile and run the SPEC CPU2006 benchmarks on x86. We are compiling and running the benchmarks on a an Intel Xeon E5540 processor running Ubuntu 10.10 (64-bit version). For the native x86-64 target, we are using the following command-line arguments: -O3 -march=core2 -mtune=core2 and are getting compile-time errors on the gamess and

Hi Jean-Marc, Suppose that the incoming rtp stream is coded by different mode(NB/WB/UWB) each frame. Can speex decoder adjust its mode per frame in real time embedded system? I think it's hard to do that, so I think it's better to add an mode parameter in the decoder interface. What do you think? Best Regards, Lianghu -------------- next part -------------- An HTML attachment was

speex_preprocess() isn't covered in the manual, is it? But, it's very easy to use. If it returns non-zero, voice was detected. Tom "Meir Yeshurun" <mt_yeshurun@hotmail.com> wrote: > > I would like to use speex_preprocess() for voice activity detection. I read > the comments in speex_preprocess.h and the relevant paragraphs in the Speex > manual. Is there

Hi all Speexers, I've done some optimization to current SVN fixed-point on ARM9E platform. If the RVDS simulator gives the MCPS(Million Cycle Per Second) value A, then actual MCPS on real CPU will be around 2*A. I don't know what cause the big gap between the simulator and real CPU. What do you think? BR, Lianghu -------------- next part -------------- An HTML attachment was

I have been trying to understand how to get the VAD algorithm working. I sent an input stream of all zeros into the preprocessor but still got a return value of 1 indicating that speech was detected. Is this feature not available with the latest release? I thought at the very least it would detect this as silence and return 0 but that does not seem to be the case. Does anyone have any

From 1.2rc1 source code: preprocess.c: /* FIXME: This VAD is a kludge */ st->speech_prob = Pframe; if (st->vad_enabled) { if (st->speech_prob > st->speech_prob_start || (st->was_speech && st->speech_prob > st->speech_prob_continue)) { st->was_speech=1; return 1; } else { st->was_speech=0; return 0; } } else { return 1; } AND case

Hi everyone, As you may have guess, Speex 1.2 is slowly approaching, though there's still a lot left to do so I can't say how long it'll take. I thought this was the right time to ask if there's anything missing or that can be improved to make 1.2 better. At this point, it can't be anything major, but there are still some changes that are possible, e.g: - Improving some

Hi Jean-Marc I am using speex in my voip app (wideband mode). I have noticed that when VAD kicks in, CPU considerably increases (bitrate decreases to 4 kbps). It takes about 7 ms to encode one frame versus 0.5 ms (for speech). This happens regardless preprocessor is used. Although the issue seems to be driver dependent, it occurs on XP, Vista and Mac OS X. Besides complexity and quality, this

Hi Ghassan, this is very interesting, however... > We are currently working on revising a journal article that describes our work > on pre-allocation scheduling using LLVM and have some questions about LLVM's > pre-allocation scheduler. The answers to these question will help us better > document and analyze the results of our benchmark tests that compare our > algorithm with

Following is the list of fp benchmarks that fail. They all pass with -O3, but some fail with -O4. I did the test run. Thanks, Reza Estimated Estimated Base Base Base Peak Peak Peak Benchmarks Ref. Run Time Ratio Ref. Run Time Ratio -------------- ------ --------- ---------

Could a method be added to use the VAD from the preprocessor to send the packet with the 'dtx_enable' flag in it, so the decoder on the other end knows it's in dtx mode? (and SPEEX_GET_DTX_STATUS returns 1) At the moment, I can hack around it by doing something like: if (VAD for prev frame && ! VAD for this frame) { iArg = 0;