similar to: speex_jitter_buffer and DTX (and multiple streams)

Hi, I'd like to report a bug in speexclient/speex_jitter_buffer.c. In the function speex_jitter_get(), after the line: packet.data = data; add the line packet.len = 2048; If this variable is uninitialized, then in jitter_buffer_get() (in jitter.c), the predicate "jitter->packets[i].len > packet->len" is undetermined. When this happens, the wrong amount of

Hi, I've a couple of questions about the jitterbuffer. First of all, I'm a bit confused about the code to use. Googling the subject I've find that there are, or there were, two jitter buffers, a generic one and a speex-specific one, is this still true or they've been joined? Downloading the 1.2rc1 source code there's no trace of the SpeexJitter structure and wrapper functions

Hi, It seems like there's a missing ... #ifdef __cplusplus extern "C" { #endif ... somewhere near the beginning of speex_jitter_buffer.h (I'm looking at the latest SVN version). Otherwise, there is nothing to match the "#ifdef __cplusplus" near the end of the file. Inserting the lines above allows my code to compile. (BTW, Speex has been working like a charm

Dear Jean, > Actually, 38 is normal for the 15 kbps mode. For the rest, could you > give more details. Also, what platform is the problematic machine? (What > CPU, what OS, what compiler). Thanks for your reply. The platform is WindowsXP Professional with SP1. CPU is Celeron CPU 1.70GHz. Compiler is VC++ 6.0. I have enabled VAD and DTX . In this computer, speex_bits_write() still

There is an error in the manual as it is now on p.39 (speex-manual.pdf)?under the speex specific jitter buffer. The error was also a part of the code untill resently (I downloaded it a few weeks ago with the error) ? The error was (in the code) in the function: voidspeex_jitter_get(,,) where the packet.len was not set to 2048. So actually there should just be inserted the statement: packet.len =

I have a video conference like application that I've been working on for a while now, and a recent change is causing some odd problems, and I was wondering if anyone else had seen problems like this. The issue I'm seeing is that when using the sound card for capture, the audio will eventually get about 1-2 seconds out of synch (delayed), from the video. However, if I use USB devices

Daniel Schmidt a ?crit : > I found the cause of the problem. The function shift_timings can > produce overflows in the timing array if the jitter is huge or the > time units are very short. After changing the timing values' type from > spx_int16_t to spx_int32_t it seems to work. Hmm, I always assumed there wouldn't be any overflows. What parameter range are you using that

Hi! I am still trying to clean the voice after procesing it with speex echo cancellation filter. I get some artifacts, the echo is removed, but you can here some metallic voices in background. Jean, in your test client you are using UDP connection and SpeexJitter to make sure UDP packets are in order. What if I use TCP/IP, do I still have to use SpeexJitter when using speex_echo_cancel ?

Dear speex developers and users, I'm considering adopting the speex jitter buffer for use with a different codec in a voice conferencing system and would be very grateful if those more acquainted with it could help me with some questions. The speex_jitter_buffer.c wrapper seems to maintain (buffer?) one packet-frame ("current_packet") in addition to the packets already

Hi Zachary, Zachary Schneirov a ?crit : > The speex_jitter_buffer.c wrapper seems to maintain (buffer?) one > packet-frame ("current_packet") in addition to the packets already > tracked by the JitterBuffer itself. Why is this necessary? That's in case there's more than one frame per packet. That way, it finds the packet, decodes the first frame it contains, and

Hello, The way you describe how the jitter buffer should be implemented makes me wonder: How does the jitter buffer works when there is no transmission? Let's say my "output" thread gets a speex frame from the jitter buffer every 20ms. What happen when there is no frame that arrived on the socket? No frames at all for a pretty long time (ie many seconds). This is my case because I

Since r12660, the speex_jitter_get with high latency doesn?t works, I have no sound. Before this release, the speex_jitter_get works in all conditions. speex_jitter_get return void, then I cannot know the reason of this problem. Regards Ouss -----Original Message----- From: Jean-Marc Valin [mailto:jean-marc.valin@usherbrooke.ca] Sent: dimanche 18 mars 2007 23:07 To: Ouss Cc:

Le mardi 02 mai 2006 ? 18:15 +0200, Thorvald Natvig a ?crit : > 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_*). Oops, I forgot to make sure I keep the API stable for the old buffer. Any thoughts on

Hi Jean, > Actually, Speex has Packet Loss Concealment (PLC) > builtin. If a packet > is missing, instead of repeating the previous one, > just try decoding by > passing NULL instead of the SpeexBits struct. > Thanks, I have made the above changes and the effect seems to be better now. > > I think jitter buffering is more correct way to > solve > > this problem

Hi Ouss, Can you test again? I think I found and fixed the problem. Jean-Marc Ouss a ?crit : > Since r12660, the speex_jitter_get with high latency doesn?t works, I have > no sound. > Before this release, the speex_jitter_get works in all conditions. > speex_jitter_get return void, then I cannot know the reason of this problem. > > Regards > > Ouss > > >

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

> Thank you for a very good explanation which shed light on some of the > questions that I had after reading the source code. > > Reading your text however, I wonder if I'm perhaps missing an important > point on the proper use of the jitter buffer: > > ... >> Now, clearly, if early_ratio is high and late_ratio is very >> low, the buffer is buffering more than

Hello Jean-Marc, thank you for your reply. > > I found the cause of the problem. The function shift_timings can > > produce overflows in the timing array if the jitter is huge or the > > time units are very short. After changing the timing values' type from > > spx_int16_t to spx_int32_t it seems to work. > Hmm, I always assumed there wouldn't be any overflows.

>> 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_*). > > Oops, I forgot to make sure I keep the API stable for the old buffer. > Any thoughts on the change (revert or continue as is)? Well, I

[The following is perhaps a long question and even off-speex topic,] [but if anyone can at least point me in the right direction for ] [alternate sources of information, I'd really appreciate it. ] When speex_jitter_get(...) is called and there is no buffer/data to return, would I not want to know that there is no true data to play? If I turn around and queue 20ms of silence to play