similar to: Voip Jitter Buffer

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

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

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:

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

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

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

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

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

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

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

Jean-Marc Valin wrote: >>I believe it is adaptive, but no, I haven't used it, because it's >>coupled only to the speex codec. We're working on a generic >>application and codec-independent jitter buffer algorithm, for use in >>asterisk and iaxclient (at least). Some information is available at

Danny Chan wrote: >Hi Jean and Steve, > >Can you tell me whether the jitter filter / buffer is adaptive type, I >saw the description of speex_jitter.h say it is "adaptive", anyone of >the group has implemented it and confirm it. > > I believe it is adaptive, but no, I haven't used it, because it's coupled only to the speex codec. We're working on a

[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

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

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