similar to: How does the jitter buffer "catch up"?

> 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

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 it needs to; it will > skip a frame

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:

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

I use the speex version of your jitter, and in speex_jitter_get, you always call the jitter_buffer_update_delay. -----Original Message----- From: Jean-Marc Valin [mailto:jean-marc.valin@usherbrooke.ca] Sent: dimanche 18 mars 2007 13:06 To: Ouss Cc: speex-dev@xiph.org Subject: Re: [Speex-dev] Problem with the svn jitter buffer > I think that the new Jitter Buffer have a problem. > >

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

>> 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

Dear all. Questions regarding VoIP implementation and the use of the Speex jitter buffer, if I may: Am I right in my understanding that the Speex jitter buffer implementation is used only on the receiving end of a network VoIP stream? 1) The sender would sample+encode+timestamp packets/frames of speex data and send via UDP to receiver. UDP packet would be constructed as: [TIMESTAMP][Speex

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

> Hello, Hi :) First off, could you try to set your email client to break long lines before transmitting? In my (somewhat outdated) pine, the lines appear as VERY long lines when I try to reply, making it hard to read :) Minor detail though, I should probably fix pine. Some day. > The way you describe how the jitter buffer should be implemented makes me > wonder: How does the

>> (PS, if you do use threads, protect speex_jitter_put/get with a mutex >> (CRITICAL_SECTION I believe they're called in Win32Speak) -- calling put >> and get at the exact same time from different threads leads to "features") > > I've never tested this, but I designed the jitter buffer to work from > two threads even without using a mutex. This would

Hello, I think that the new Jitter Buffer have a problem. It works perfectly when I call the speex_jitter_put every 20ms (on my lan) but in other case (with big latency on Internet connexion), it doesn't works. The old version is OK in all cases. Hope it will helps. Thanks Ouss -------------- next part -------------- An HTML attachment was scrubbed... URL:

> (PS, if you do use threads, protect speex_jitter_put/get with a mutex > (CRITICAL_SECTION I believe they're called in Win32Speak) -- calling put > and get at the exact same time from different threads leads to "features") I've never tested this, but I designed the jitter buffer to work from two threads even without using a mutex. This would work as long as there is

Is is possible to give a short hint about how the jitter buffer would "catch up" when network condition have been bad and then get better? I'm using the jitter buffer with success now, but sometimes I have a long delay that's caused by bad network conditions and then later when the conditions get better, I would think we would want the audio to gradually catch up with real-time

Patch applied offline (I'm in the plane), remind me if I forget to push it. About the "resync on burst" issue, I was aware of it, but I'm not sure how to fix it. Any idea? Also, do you see the problem happening often? Jean-Marc Thorvald Natvig a ?crit : > > The jitter buffer would "freeze" under the following condition: > > - The sender and receiver are

> OK, I'm actually about ready to start working on this now. > > If people in the speex community are interested in working with me on > this, I can probably start with the speex buffer, but I imagine > there's going to be a lot more work needed to get this where I'd like > it to go. And where would you like it to go? ;-) > At the API level, It seems pretty easy

('binary' encoding is not supported, stored as-is) I'm working on a voip project with Speex and the only major design obstacle left (that I'm aware of) is the jitter buffer. Before I attempt to write something of my own I'd like to try out the jitter buffer functions in Speex's unstable release. Can anyone give me a basic run down of how the experimental jitter buffer is

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

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