similar to: RTP and jitter buffer relationship

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

[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

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

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:

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

Hi Jean-Marc, Thanks for your response. Given a worst case scenario, what is the "worst case" latency (in terms of Speex frames) that the jitter buffer algorithm will incur? We're trying to determine the worst case hard number. Sorry for unclear question below; what I was trying to ask is that given a worst case latency (which I'm asking in the first question) inherent in

Hi all I have seen that, for speex 1.1.6, there is a jitter buffer implementation. I´d like to know, please, what kind of jitter algorithm it´s been used to implement it. Is there anything like an algorithm overview or something else that someone could send me? Thanks in advance and best regards Guild __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new

-----Original Message----- From: speex-dev-bounces@xiph.org [mailto:speex-dev-bounces@xiph.org] On Behalf Of Thorvald Natvig Sent: Monday, March 20, 2006 12:11 PM To: speex-dev@xiph.org Subject: Re: [Speex-dev] Who is using the jitter buffer? But I must say that it really does work well at the moment, at least from the "minimizing latency" point of view :) How do you timestamp the

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

> 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

Jean-Marc Valin <Jean-Marc.Valin@USherbrooke.ca> wrote: > > > I would think you might also do better if you interleaved packets when > > you did this: instead of sending packets like this: [0,1] [2,3] [4,5] > > [6,7], send them like this: [0,2] [1,3] [4,6] [5,7] In this way, if one > > packet is dropped you don't lose two consecutive voice frames. >

> FYI: The below is just my interpretation of the code, I might be wrong. Most of it is right. Actually, would you mind if I use part of your email for documenting the jitter buffer in the manual? > Each time a new packet arrives, the jitter buffer calculates how far ahead > or behind the "current" timestamp it is; this is called arrival_margin. > The "current"

On 5/3/06, Jean-Marc Valin <Jean-Marc.Valin@usherbrooke.ca> wrote: > > I must say I really like the generalized jitter buffer though :) It's a > > cleaner and more flexible implementation and can more easily be adjusted > > to contain additional information with each packet. This looks interesting to tie into asterisk's jb and plc code as well.

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

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. Thank you all. Regards, Danny Chan -----Original Message----- From: speex-dev-bounces@xiph.org [mailto:speex-dev-bounces@xiph.org] On Behalf Of Jean-Marc Valin Sent: Tuesday,

> Err, unless I'm totally wrong, there are a few race conditions. > > Assume the buffer is full of packets newer than the current pointer, and > one that is at the current pointer. > > get and put start at the same time. > > get will find the correct buffer index. Now, just after it finds it's > index, assume we switch to the put thread. > > Put needs

> how about tcp? > in tcp you write a packet that got a possible length. > you send one packet after another, whitch stamp is incrementet by one > and if your incoming packet is gone in other steps than 1, the client has > to resend it. > Let me think some days about it and i will get another system. > Time is relative. > > Hm, you send a packet that needs to be in a

[sorry for the loss of proper attributions, this is from two messages]: [Me] >This is something I've encountered in trying to make a particular > asterisk application handle properly IAX2 frames which contain either > 20ms of 40ms of speex data. For a CBR case, where the bitrate is > known, this is fairly easy to do, especially if the frames _do_ always > end on byte