similar to: Who is using the jitter buffer?

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

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

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

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

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

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

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

> 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

Hi. 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_*). However, a lot of warning: did you forget to call jitter_buffer_tick() by any chance? is displayed. Looking at speex_jitter_get, the logic seems to be as follows: if

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

Hi, I'm moving my "metadata" which accompanies some of the speech packets into the speex bits. However, as usual, I'm a bit confused. The manual (PDF from current SVN), section 5.10 (bottom of page 21) states that: "Finally, applications may define custom in-band messages using mode 13. The size of the message in bytes is encoded with 5 bits, so that the decoder can

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

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

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

> 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

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

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

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: