similar to: summer of code

Not a big deal, but the "<http://xiph.org/svn.html>Subversion Access" link on http://www.speex.org/download.html page should probably point to: http://www.xiph.org/svn/ rather than: http://xiph.org/svn.html Tom ______________________________________________ Tom Harper Lead Software Engineer SightSpeed - <http://www.sightspeed.com/>http://www.sightspeed.com/ 918 Parker

Jean-Marc, So I saw in the latest code that the vad in the preprocessor is gone/going to be re-written. Is there a plan as far as this goes? Just wondering as the current one seems to work pretty well. Thanks! Tom ______________________________________________ Tom Harper Lead Software Engineer SightSpeed - <http://www.sightspeed.com/>http://www.sightspeed.com/ 918 Parker St, Suite A14

re: At 03:22 PM 10/25/2005, Jean-Marc Valin wrote: >Are you really sure you didn't have some corruption elsewhere? Totally possible- this is the first time this has happened that I know of in many many hours of usage- On the other hand, this null check isn't in my code base and it was in nb_decode_lost, and nb_encode- so I figured it was just an oversight- Tom

Hi, So I got a crash on the following code: k1=SUBMODE(lpc_enh_k1); k2=SUBMODE(lpc_enh_k2); which in the newer codebase is: bw_lpc(SUBMODE(lpc_enh_k1), st->interp_qlpc, awk1, st->lpcSize); bw_lpc(SUBMODE(lpc_enh_k2), st->interp_qlpc, awk2, st->lpcSize); I am not sure if the newer code will have the same issue but the following check is

At 12:35 PM 10/6/2004, Matthias Granberry wrote: >There is some SSE assembly >language, but it's in GCC/AT&T syntax rather than the windows-standard >Intel syntax, so you might have to do some of your own translation to >something your compiler understands. We submitted an intel patch a ways back- maybe it is in the archives somewhere... Tom -- Tom Harper -

Hi Jean Marc & List, So I have been fiddling with the denoiser (again). While poking around I noticed that nb_preprocess is basically a counter that is mod-ded with 100 (the default), which causes Smin[] to be re- seeded with the value in Stmp[] (min of the previous adaptation period). Smin[] is then used to update the noise probability, which is (probably) less likely when adaptation

Hi everyone, I'm currently attempting to move Speex development over to Git. Because Git is distributed, I means that anyone would be able to do development and commits without having to get write access (and I can just pull from them). There are of course other advantages, like sane handling of branches and tags, local history, ... Now, one of the disadvantages is that Git currently

I'm not sure if this is due to the same problem, but I get the same clipping behavior when trying to use VAD+denoiser on a particular mic+speaker setup that has significant background noise (enough to really foul up the codec should the denoiser be turned off.) Leaving VAD off and transmitting continuously seems to be the only way to avoid this clipping. Another person I regularly

Current SVN compilation fails on Win32 (Intel C++ compiler 9.0): ..\..\libspeex\mdf.c(317): error: declaration may not appear after executable statement in block float adapt_rate; Just moved it up to the variable declaration block to solve it locally, but as it's not valid C, I thought I'd mention it ;) PS: With the same compiler, AGC fails horribly (Zlast goes to several

Jean Marc, I ran across the silence issue that results from the echo canceller producing "bad" floating point data. Unfortunately this hasn't been done in a way i can reproduce, but I found that calling reset didn't fix the silence, unless I also reset: st->PHI[i] st->Eh[i] st->Yh[i] So it may be good to add these to the reset function. I was using these in

That's definitely strange and I've never encountered that. Normally, the only way for _mm_load_ups to generate a segfault is for the input to be invalid memory, in which case the C version should crash too. I suspect the compiler (or something else) may be hiding the real problem. Can you get a debugger and see exactly what assembly statement is causing the crash and what the operands are?

Jean Marc, So the C99 array syntax is breaking some lesser compilers- is there a known max size for bark[]? Fiddling with latest svn again... Thanks! Tom ______________________________________________ Tom Harper Lead Software Engineer SightSpeed - <http://www.sightspeed.com/>http://www.sightspeed.com/ 918 Parker St, Suite A14 Berkeley, CA 94710 Email: tharper@sightspeed.com Phone:

There is a port to mingw, which is what many folks use now: http://repo.or.cz/w/git/mingw.git I haven't had a chance to fiddle with it yet so ymmv. Tom At 06:00 AM 6/9/2007, Jean-Marc Valin wrote: >Hi everyone, > >I'm currently attempting to move Speex development over to Git. Because >Git is distributed, I means that anyone would be able to do development >and commits

Jean Marc, Ok so I tested with the new code, same result- frame size= 160, filter length=160 ms/1280 samples, 8000 Hz diverged after 9564 calls/packets or 191 seconds. My system stays relatively in synch but is not perfect- difficult to measure if there is any clock drift, but it probably is. In order to make it break faster I use an open air usb microphone that is part of a logitech notebook

Jean Marc & list, Following up on this- there seems to be an issue with this calculation in mdf.c (Smooth echo energy estimate over time) Pey += Eh*Yh; Pyy += Yh*Yh; it goes too large for floating point, which seems to be caused by extremely large values in st->Rf[j], st->Yf[j] and smaller values in st->Eh[j], st->Yh[j]- things were relatively quiet

Hi Jean Marc and List, So I have started finally fiddling around with Ultra-wideband mode. It appears to be very similar in operation to Wide mode, except that when peering into the packet structure it looks like (and these are kind of questions as much as statements here): 1. update rate 0 is not used in UWB- only 1-4? 2. The total bits used for each UWB update rate seem to be as follows:

Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: preproc_patch_dth_10_26_05.patch Type: application/octet-stream Size: 8774 bytes Desc: not available Url : http://lists.xiph.org/pipermail/speex-dev/attachments/20051026/c27a3ed6/preproc_patch_dth_10_26_05.obj

Jean Marc, I have been fiddling around with preprocess to try to get it sounding less metallic/underwater- so based on some things said recently, I have been first fiddling with mean_post and mean_prior to try to get them to do change the update rate, so that update_noise gets called at the right times. Haven't made it too deep into the code, but I have a few questions in speex_preprocess:

Hello The st->zeta pointer isn't freed in the speex_preprocess_state_destroy() function of the preprocess.c file (alloced in line 167). It's in Speex 1.1.4 by the way. I'm trying to make the denoiser work with my application and has got reasonable noise reduction after applying the denoiser. I, however, haven't been able to find any information of what the purpose of

Hey, thanks for sharing this information. If this is true, it could explain some intermittent problems I've had, since I do encoding and decoding in separate threads. I assumed that Speex was thread-safe because there doesn't seem to be a connection between the encoder and decoder, and the encoder and decoder require separate states for different streams. I'm curious to know