similar to: JitterBuffer in SVN

Jean-Marc Valin wrote: > Thorvald Natvig a ?crit : > >> I see you're changing the jitter buffer around quite a bit. Could you >> let us know when it's ready for general testing? (At the moment it >> doesn't handle missing packets at all) >> > > While I'm not completely done yet, I thought the current version was > working. Can you tell

Thorvald Natvig a ?crit : > I see you're changing the jitter buffer around quite a bit. Could you > let us know when it's ready for general testing? (At the moment it > doesn't handle missing packets at all) While I'm not completely done yet, I thought the current version was working. Can you tell me what happens exactly (without output if possible) so I can fix it? Also,

Hi, I'm moving my "metadata" which accompanies some of the speech packets into the speex bits. However, as usual, I'm a bit confused. The manual (PDF from current SVN), section 5.10 (bottom of page 21) states that: "Finally, applications may define custom in-band messages using mode 13. The size of the message in bytes is encoded with 5 bits, so that the decoder can

The jitter buffer would "freeze" under the following condition: - The sender and receiver are in sync. - The sender machine freezes for a few seconds while the receiver does not. - This causes all the packets sent by the sender to have a timestamp that is too low to be considered, meaning jitter_buffer_put ditches it before it checks if lost_count > 20 to reset. - The jitter buffer

Oh, I forgot to mention one thing. I currently append a few bits of custom information to each speex packet which I fetch out with things like speex_bits_unpack_unsigned(&sjJitter.current_packet, 1); It would be very usefull if the jitter buffer didn't actually decode the packet, but instead returned a pointer to it (or NULL if you should play silence and -1 if you should repeat the

Jean-Marc Valin wrote: >> Once I updated the application to use the updated function call, the >> jitter buffer worked again, giving sane results even with +/- 30 ms >> arrival times and 20% packet loss. So sorry for bothering you with a >> bogus bug report :( >> > > Happy to hear it works. ...but I'm still interesting on test data for > the jitter

Alexander Chemeris wrote: > Hi, > > On 5/27/08, Thorvald Natvig <thorvald at natvig.com> wrote: > >> And here's a patch for Intel Math Kernel Library. This allows commercial >> users of Speex to use a high-speed FFT library that isn't GPL'd. (You do >> need to pay for it though). This is 3 times faster than the default FFT in >> speex, and

Hi, The attached patch fixes an incistency in my earlier patch. Whereas the rest of the AGC ctls are in dB, GET_AGC_GAIN was linear. This patch fixes that. It also changes the API for _GET and _SET_AGC_LEVEL to use a int32 instead of a float, meaning we don't need to do a API change when we get a fixed point AGC. Best regards, Thorvald -------------- next part -------------- ---

Hi, Attached is a patch which enables FFTW3 to be used by libspeexdsp. Using SSE, the FFT code is more than twice as fast, and it's 50% faster even without SSE. To enable the library, you'll need to call configure with '--with-gpl-fftw3'. Based on the benchmarking we did, this also changes the default FFT to smallft for floating point implementations when not using FFTW3.

Alexander Chemeris wrote: > Hi, > > Here are some questions from user point of view. :) > > On 5/29/08, Thorvald Natvig <thorvald at natvig.com> wrote: > >> I've done listening tests when converting wb_male.wav to 44.1, 48 and 8khz, >> and there aren't any obvious artifacts. I also did a 16=>16 test, and the >> results are delayed by 10ms

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;

Thorvald, re: At 03:18 AM 1/6/2006, Thorvald Natvig wrote: >I just checked it in the debugger, and this was with gcc 3.4.4 (mingw)... >And the addresses were not properly aligned :( From a bit of googling, >this seems to be a thread problem, as the gcc just maintains 16-byte >alignment of the stack -- if the start function of the thread had >misaligned stack, the misalignment

Hi. After changing my code to construct a JitterBufferPacket and passing that to speex_jitter_put, my program works with the new jitter buffer using the wrapper functions (speex_jitter_* instead of the new jitter_buffer_*). However, a lot of warning: did you forget to call jitter_buffer_tick() by any chance? is displayed. Looking at speex_jitter_get, the logic seems to be as follows: if

pwk.linuxfan@gmx.de wrote: > On Sunday 08 July 2007 02:24, Thorvald Natvig wrote: > >> Next, and slightly unrelated question: >> Why does >> int jitter_buffer_update_delay(JitterBuffer *jitter, JitterBufferPacket >> *packet, spx_int32_t *start_offset); >> include the packet parameter? It's not used in the code, and it also >> makes the API slightly

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

Hi, I'd like know about anyone using the current jitter buffer in Speex. I'm planning on changing it to make it more general and I'd like some feedback about how to make it better. Also, let me know if you're doing anything serious with it and want to make sure I don't break your stuff. Basically, I want to make the jitter buffer easier to use with other codecs and reduce the

Hi, I've attached a patch against SVN r14645 which adds GCC visibility information to all symbols exported from libspeex.so and libspeexdsp.so. It includes a configure.ac change to test that both the compiler flags and __attribute__((visibility)) works, and if so will #define EXPORT __attribute__((visibility("default"))) and if not #define EXPORT I've attached a diff output

And here's a patch for Intel Math Kernel Library. This allows commercial users of Speex to use a high-speed FFT library that isn't GPL'd. (You do need to pay for it though). This is 3 times faster than the default FFT in speex, and also faster than FFTW3 since MKL has native support for the complex packing Speex uses. Since Intel hasn't supplied any pkg-config files, and which

From: Thorvald Natvig <slicer at users.sourceforge.net> Some optimizing compilers miscompile the current SSE optimizations when full optimizations are enabled. By using output value pointer instead of a return value, we can bypass this misbehaviour. --- libspeex/resample.c | 8 ++++---- libspeex/resample_sse.h | 24 ++++++++---------------- 2 files changed, 12 insertions(+), 20

From: Thorvald Natvig <slicer at users.sourceforge.net> --- celt.pc.in | 2 +- configure.ac | 2 ++ libcelt/Makefile.am | 12 ++++++------ tests/Makefile.am | 2 +- tools/Makefile.am | 4 ++-- 5 files changed, 12 insertions(+), 10 deletions(-) diff --git a/celt.pc.in b/celt.pc.in index 98cc008..67a830b 100644 --- a/celt.pc.in +++ b/celt.pc.in @@ -10,5