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

Displaying 20 results from an estimated 2000 matches similar to: "How does the jitter buffer "catch up"?"

2005 Sep 18
2
How does the jitter buffer "catch up"?
> 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"
2005 Sep 18
2
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 it needs to; it will > skip a frame
2007 Mar 08
4
Introduction and patch
Hi, I'm one of the people working on the Rockbox project (http://www.rockbox.org) which is an open source alternative firmware for a range Digital Audio Players. Recently we integrated support for the Speex codec using libspeex and seems to work well. If you could add Rockbox to your list of software that supports Speex, that'd be great. So that's the introduction done. Now for
2005 Sep 18
0
How does the jitter buffer "catch up"?
> > 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
2005 Sep 18
0
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
2016 Jun 12
2
Patches for adding 120 ms encoding
Hi Felicia, A few comments: > - /* CELT can only support up to 20 ms */ > subframe_size = st->Fs/50; > - nb_subframes = frame_size > st->Fs/25 ? 3 : 2; > + nb_subframes = frame_size/subframe_size; This will use six 20ms frames to make a 120ms packet, even for SILK-only mode where frames can be up to 60ms. For SILK, two 60ms frames would be a more
2004 Nov 16
2
Jitter buffer
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
2016 Jun 27
2
Patches for adding 120 ms encoding
Attached is the amended second patch. It now extends the multistream API as well to 80/100/120 ms and incorporates changes based on Mark's comments. Thanks, Felicia On Mon, Jun 13, 2016 at 4:21 PM Felicia Lim <flim at google.com> wrote: > Hi Mark, Jean-Marc, > > Thanks for your comments. > > On Sun, Jun 12, 2016 at 6:34 AM Mark Harris <mark.hsj at gmail.com>
2016 Jun 10
2
Patches for adding 120 ms encoding
Hi, I wondered if are there any further thoughts on these patches? Thanks, Felicia On Thu, Jun 2, 2016 at 2:13 PM Felicia Lim <flim at google.com> wrote: > OK, I've amended the second patch and also added 80 and 100 ms. > > Thanks, > Felicia > > > On Thu, Jun 2, 2016 at 7:20 AM Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > >> On 06/01/2016 02:06
2005 Sep 22
0
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
2006 Mar 19
3
Who is using the jitter buffer?
Hi, I'd like know about anyone using the current jitter buffer in Speex. I'm planning on changing it to make it more general and I'd like some feedback about how to make it better. Also, let me know if you're doing anything serious with it and want to make sure I don't break your stuff. Basically, I want to make the jitter buffer easier to use with other codecs and reduce the
2004 Nov 15
2
Jitter buffer
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
2007 May 08
2
asterisk 1.2 and UDP packet numbering on bridged channels (for jitter buffering)?
http://www.asterisk.org/node/48317 does a nice job of explaining the 1.4 jitter buffer, however it raised a question in my mind. In 1.2 (and also 1.4), when asterisk bridges 2 SIP channels, are the UDP RTP packets renumbered on transmit, or is the original sequence number preserved in the UDP header? A comment is made on the referenced blog that jitter buffering is best implemented at the
2016 Jun 28
1
Patches for adding 120 ms encoding
Hi Ulrich, thanks for the suggestion. My concern is that one of the valid inputs is "2.5", which would require conversion to an int, e.g. x10, but doing something like this would start to affect the code readability. On Mon, Jun 27, 2016 at 3:02 PM Ulrich Windl < Ulrich.Windl at rz.uni-regensburg.de> wrote: > Hi! > > A note on style: Looking at this chunk of the patch
2005 Feb 14
5
Sipura g729 call quality to PSTN
If this has been covered before - I appologize. We use some Sipura SPA-2000's with the g711 codec and all seems fine (except for the occasional failure to register errors in my asterisk logs - but I will save that for another post). g711 call quality is on par with our Cisco 7960's. However, when using the g729 codec, the call quality on the Sipura device goes downhill on the PSTN side
2004 Aug 06
1
Speex settings and jitter
[Just curious, and seizing the opportunity to communicate with other folks who are doing the same kind of thing I am...] How are you measuring the latency? I tried measuring it with my program (also Win32-based, also using DirectSound[Capture]) and came up with around 130ms. To measure it, I placed the mic near a speaker to get feedback going, had my program connect to itself (local
2004 Nov 17
3
Jitter buffer
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:
2005 Jul 22
8
Latency of Linux Bridge
Hi there! I am working a lot with VoIP in my company, so I thought to use linux bridge functionality together with tc to emulate delay, jitter, packet loss, duplication, reordering etc. for testing purposes in our lab against our VoIP products. I just recognized, that a basic bridge just with it''s minumum configuration of 2 network interfaces creates latency of approx. 5ms on very low
2004 Sep 20
2
Garbled voice on long distance calls
I've been having random problems when I make long distance calls using either VoicePulse or Nufone. Sometimes the calls go through clear, and other calls (or even just part of a call) the person on the other end just hears garbled voice, or really broken up voice. Sometimes it lasts for only a few seconds, but other times it goes on for a few minutes until I give up on the call. At
2006 Mar 20
1
Who is using the jitter buffer?
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. >