similar to: Re: Who is using the 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:

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

> 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

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.

> Hello, Hi :) First off, could you try to set your email client to break long lines before transmitting? In my (somewhat outdated) pine, the lines appear as VERY long lines when I try to reply, making it hard to read :) Minor detail though, I should probably fix pine. Some day. > The way you describe how the jitter buffer should be implemented makes me > wonder: How does the

> 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. > clock skew: (see discussion, though) Clock skew is one of the main

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

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,

> 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

> 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

Hello all, I am currently investigating the JitterBuffer struct provided in the Speex library, and I am actually thinking about using it with two different codecs: namely, Speex-NB and AMR-NB. From looking at the code, it seems that JitterBuffer is capable of working for any codec. Both Speex-NB and AMR-NB (and probably also other narrowband codecs) produce 20 ms frames and the sampling frequency

Hi all, I have recently added Speex support to my app (http://sbooth.org/Max/) and am in the process of creating a GUI for the user to control the codec parameters. I am new to Speex and as such I am not really sure which parameters are more important than others, and deserve prominent placement, etc. Is there a recommended GUI for people to follow or use as an example? Stephen

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

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

Hello, We are in the process of debugging a voice quality issue for a client of ours that is a VoIP services provider. The client uses a softphone that runs on a pjsip stack. When placing a call using the softphone, it negotiates the use of G729 codec with the remote endpoint (ptime = 20ms). The endpoint transmits RTP packets with encoded G729 payload. VAD/DTX is enabled. We see that the last

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

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

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

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