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

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

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

> 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

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

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

Jean-Marc Valin wrote: >>Heh. I guess after playing with different jitter buffers long enough, >>I've realized that there's always situations that you haven't properly >>accounted for when designing one. >> >> > >For example? :-) > > I have a bunch of examples listed on the wiki page where I had written initial specifications:

Jean-Marc Valin wrote: >>In particular, (I'm not really sure, because I don't thorougly >>understand it yet) I don't think your jitterbuffer handles: >> >>DTX: discontinuous transmission. >> >> > >That is dealt with by the codec, at least for Speex. When it stops >receiving packets, it already knows whether it's in DTX/CNG mode.

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

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

Hi, Is there are document where the interaction between all the configuration options of speex is explained? Speex seems to have CBR, VBR and ABR. You can also use SPEEX_SET_QUALITY (SPEEX_SET_VBR_QUALITY) and SPEEX_SET_BITRATE which I suppose can't be set at the same time. Is there a list of possible combinations somewhere? I also have another question related to jitter. To minimize jitter,

>> 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? It would be my pleasure :) >> early_ratio_XX is the sum of all the positive bins. >> late_ratio_XX is the sum of all the negative bins. > > Right. And only the

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

hi, >.. And equally important; during discontignous transmission, in which >there may be small communication pauses (of either 3 seconds or several >minutes), it would be beneficial if the jitter buffer remembered it's >current estimates instead of resetting to the default. just my two cents. even during discontinuous transmission, i am looking at minutes of pauses, there should

> 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

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

>> (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 understand that only the destination of a call should do jitter buffering. So, if IAX2/PhoneA calls IAX2/PhoneB through my server (no transfers), PhoneA and PhoneB need to perform their own jitter buffering, and Asterisk will just forward the frames, correct? What happens if the peer does not support jitter buffering, but is close by so there's no need for jitter buffering? My

Dear all, i have noticed some strange behaviour in the ?jitter? function in R. On the help page for jitter it is stated that "The result, say r, is r <- x + runif(n, -a, a) where n <- length(x) and a is the amount argument (if specified).? and "If amount is NULL (default), we set a <- factor * d/5 where d is the smallest difference between adjacent unique (apart from fuzz) x

Dear all, i have noticed some strange behaviour in the ?jitter? function in R. On the help page for jitter it is stated that "The result, say r, is r <- x + runif(n, -a, a) where n <- length(x) and a is the amount argument (if specified).? and "If amount is NULL (default), we set a <- factor * d/5 where d is the smallest difference between adjacent unique (apart from fuzz) x