similar to: Proper use of jitter-buffer "margin" parameter.

On May 5, 2008, at 6:58 PM, Jean-Marc Valin wrote: > Joshua Gargus wrote: >> Our app needs to support multiple media types, so GStreamer would >> seem >> to be the obvious choice. However, voice quality is paramount for >> us. Are there any disadvantages to using the Speex plugin for >> GStreamer as opposed to directly coding to the Speex API? > >

Josh, Yes, you can change VBR quality or ABR average bitrate at any time. You don't need to do anything special. I use this feature (changing VBR quality midstream) from time to time and it's quite convenient. Tom Joshua Gargus <schwa at fastmail.us> wrote: > > Hi there (from speex-dev newbie), > > Is it possible to change the target VBR on the fly? The

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 have a really good high speed connection on my dedicated server, but I still get jitter even if there is only 1 call going on at a time. Will tweaking my iax.conf's jitter buffer settings really make any significant difference? Does anyone have a really good example that they have found to work good, besides the default one? Thanks for any help in advance!

Hello. I'm having Asterisk 1.6.0.x and trying to solve the issue concerning with a bad quality of voice for incoming SIP calls into the app_meetme. As I know, in my case of calls, jitter buffer is NOT executed on anyone channel. So, after reading Russell Bryant's post ( http://www.russellbryant.net/blog/2007/10/09/asterisk-jitterbuffer-support-for-applications/) I added following scheme

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

I am trying to using Speex for some Wireless voice transfers. I am using the 8K narrow band but am feeding it 11025 sample rate. Each Speex frame is about 14.5ms instead of 20ms. In order to minimize WiFi packet traffic I am sending 7 Speex frames at a time for a packet rate of about 10 per second so each WiFi packet has about 101ms of voice data. I have three modes 1. Simplex - voice messaging

Hi, I know that there was a jitter buffer patch (for sip) for the 1.0.9 branch some time agin. At this time, we can not upgrade to 1.4.x. Is there a useable, fairly stable INCOMING sip jitter buffer patch? That is.. I want Asterisk to jitter buffer incoming SIP packets. -------------- next part -------------- An HTML attachment was scrubbed... URL:

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

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

Hi everyone, I just changed the meaning of the timestamp in the jitter buffer. If you don't know what I'm talking about, then you're not affected. If you do use the jitter buffer, than you will need to change your code accordingly, so instead of bumping the timestamp by 20 (ms) for each frame, you'll have to increase by 160 (samples) for narrowband or 320 for wideband. The new

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.

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

> 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

Hi, I would like to test chan_sip with a bigger jitter buffer. Does anybody know where in the code this is defined? I looked through it but could not find where. If anybody else can find it please let me know. Regards, Andres

> 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

> 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

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

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: