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

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

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

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

> 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

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

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

> 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

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 see you're changing the jitter buffer around quite a bit. Could you let us know when it's ready for general testing? (At the moment it doesn't handle missing packets at all) Best wishes, Thorvald

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

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

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

> 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

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 Zachary, Zachary Schneirov a ?crit : > The speex_jitter_buffer.c wrapper seems to maintain (buffer?) one > packet-frame ("current_packet") in addition to the packets already > tracked by the JitterBuffer itself. Why is this necessary? That's in case there's more than one frame per packet. That way, it finds the packet, decodes the first frame it contains, and

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