similar to: jitter buffer implementation in speex

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

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, Our project is using the jitter buffer feature built in Speex. We noticed there are some latency when using the jitter buffer. Does anyone know what is the "worst case" latency inherent in the jitter buffer algorithm? I believe someone already mentioned that it's adaptive but is there a worst case hard number (in terms of 20ms Speex frames)? I'm not familiar with 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 work as long as there is

Jean-Marc Valin wrote: >>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

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

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

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

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

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

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

> 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

Hmm, I tried... I completly understand an idea of jitter buffer and I know there is a lot of kinds of this solution (eg. AJB - Adaptive Jitter Buffer). I simply want to know what type is used in speex codec and how could I use that. What is the reason for using jitter buffer implemented in speex against to my own (implemented at lower layer - transmission layer - eg. rtp). Kapul On Tue, Sep

Greetings list, Some time ago (probably about a year ago now) we disabled IAX jitter buffering on all our boxes because it was causing issues in a mixed 1.0 and 1.2 environment. One thing I've noticed over the last few months as more and more clients have moved from the 512k/1mb/2mb ADSL connections they were using onto "up to 8mb" connections is that whilst overall throughput is a

Hi, I know that there was a jitter buffer patch (for sip) for the 1.0.9 branch some time agin. At this time, we can not upgrade to 1.4.x. Is there a useable, fairly stable INCOMING sip jitter buffer patch? That is.. I want Asterisk to jitter buffer incoming SIP packets. -------------- next part -------------- An HTML attachment was scrubbed... URL:

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, I have a SIP client which is registered to asterisk. Asterisk is registered to a SIP trunk and also handles the media. Now since my client has some issues in its RTP Tx, which seems to have some amount of jitter (mean jitter as per ethereal trace is about 17ms, max jitter is 20 ms and max delta is 85 ms), to over come that I have enabled jitter buffer in the SIP channel by setting sip.conf

Hi All, I have a question regarding the nominal jitter buffer configuration: The call was setup as G.729A (annexb=no), ptime=20ms and nominal jitter buffer size = 50ms, and round trip delay is 200ms, the TDM side will experience intermittent one way voice during the call, but IP side can always heard the voice from TDM side. My question is, should this possible caused by the nominal jitter

Hi, I thought I'd repost this to the -users list for some background on the jitter buffer and its workings and remaining issue.s I'll also pu a little executive summary here at the top: Where a channel is native bridged to another iax2 channel: 1) Lag is not measured and will usually show 0ms. Any other number is an old measurement from the start of the call 2) The jitter

Hi List, I have a question regarding jitterbuffer in Asterisk 1.4.24. I see that jitterbuffer is only effective on the receiving channels. My asterisk has only SIP accounts + 2 SIP trunk accounts to our branch office. Questions: 1. To enable jitter buffer on SIP channels it seems I have to enable and force it, right? 2. If I enable and force jitter buffer, Asterisk would always have to stay