similar to: Who is using the jitter buffer?

Thorvald Natvig wrote: >> 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

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

> That's basically my question: the timestamps at the source and > destination are not related. Just incrementing by number of samples > doesn't really convey the real time, does it? How would a jitter > buffer know that a packet is late/early? Simple, I know what packet I just played. That gives me the "time". The jitter buffer actually makes no difference (and

> 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

> what happens if this number flows over? It is just a "int", so it might reach > its limits at 2^15 = 32768, that happens after 102 puts... I would say that an int is 32 bits :-) Actually, RTP defines the timestamp as a 32-bit value. Now, what happens when it overflows (3 days for narrowband), I don't know what the RFC says about it. > In my current > implementation

> My C book taught me an int is only guaranteed to be 16bits or bigger, and > since I am trying to write code that doesn't break on other systems, I am > assuming the "worst case". Hence I have to deal with the overflow... Is my > information that "int" can be 16bit (a) false or (b) true but not valid for > any relevant architecture? c) assumes that I

> That's basically my question: the timestamps at the > source and > destination are not related. Just incrementing by number of samples > doesn't really convey the real time, does it? How would a jitter > buffer know that a packet is late/early? > Simple, I know what packet I just played. That gives me > the "time". The jitter buffer actually makes no

> 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

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

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

Hello Jean-Marc, thank you for your reply. > > I found the cause of the problem. The function shift_timings can > > produce overflows in the timing array if the jitter is huge or the > > time units are very short. After changing the timing values' type from > > spx_int16_t to spx_int32_t it seems to work. > Hmm, I always assumed there wouldn't be any overflows.

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

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

-----Original Message----- From: Jean-Marc Valin [mailto:Jean-Marc.Valin@USherbrooke.ca] Sent: Monday, March 20, 2006 2:22 PM To: Alex Bakaev Cc: Thorvald Natvig; speex-dev@xiph.org Subject: RE: [Speex-dev] Who is using the jitter buffer? The timestamps always increment by 160 (samples) in narrowband and 32 in wideband. It's like using the capture soundcard as clock. Note that the timestamps

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

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

It seems that speex jitter buffer is tightly coupled with SPEEX codec [we have to give a speex decoder instance to JB]. It would be better if we could use it with any codec, like speex preprocessor and AEC. What are the any paper/theory/algorithms behind current ADAPTIVENESS of speex JB? Links to those algo/papers would help to understand better. -- Shantanu --- Thorvald Natvig

> 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 think the only difficult part here that you do is dealing with > multiple frames per packet, without that information being available > to the jitter buffer. If

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

On Wednesday 05 October 2005 13:53, Jean-Marc Valin wrote: > > what happens if this number flows over? It is just a "int", so it might > > reach its limits at 2^15 = 32768, that happens after 102 puts... > > I would say that an int is 32 bits :-) Actually, RTP defines the > timestamp as a 32-bit value. Now, what happens when it overflows (3 days > for narrowband),