similar to: Jitter buffer latency

Hi, I looked at the jitter buffer code and it seems like the maximum number of frames that Speex can hold up to is 200 (SPEEX_JITTER_MAX_BUFFER_SIZE). This is equivalent to 4 seconds (20msec/frame * 200 frames). Can I just reduce this constant to limit the size? I know I'll reduce the smoothness of delayed frames but I want to reduce the delay in case my audio application isn't

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I was just measuring the bitrates of a couple of codecs via iax. I'm getting much higher numbers than expected, so maybe I'm doing something wrong? Measured with iptraf, values displayed are: codec: measured bitrate (bitrate according codec definition) gsm: 52 kbps (13 kpbs) alaw: 154 kbps (?) speex: 57 kpbs (24 kpbs) Seems a little

jitter varioues from application to application and network to network. let me give you an instance from my own work. i am using speex in a voip application that has to work on gprs connection. the gprs gives just 9.6 kpbs up. hence, i have an upper limit of 6kpbs on the codec and not more than 5 udp packets per sec. that means, putting in 10 speex frames in every rtp packet. i need to jitter

> FYI: The below is just my interpretation of the code, I might be wrong. Most of it is right. Actually, would you mind if I use part of your email for documenting the jitter buffer in the manual? > Each time a new packet arrives, the jitter buffer calculates how far ahead > or behind the "current" timestamp it is; this is called arrival_margin. > The "current"

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

Hi I currently have a 3072kbps line that I'm splitting in half for 5 of my phones. That's 307.2kbps +/- a couple of kpbs. What is the minimum kbps for a phone to maintain clarity and volume? Joshua

Hi, sorry for the repost again, but does anyone have a code snippet example of how to use the jitter buffer? Regards, Andy ----- Original Message ---- From: Andy Ngo <ndno72-speex@yahoo.com> To: speex-dev@xiph.org Sent: Wednesday, January 10, 2007 8:09:10 PM Subject: [Speex-dev] Sample snippet of how to use jitter buffer Hi, I searched around in the Speex manual and API but

The problem is that the mp3 dewdz will be used to looking at bitrates to determine quality, so the solution (as several here say) seems to me to just rip out anything mentioning bitrate from the simple tools. But, they will still see the bitrate in players like winamp. To solve this, why not store the quality setting used when encoding into the ogg file itself ? Either use a field unused when

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

Greetings, With all the press concerning the 'almost 1.0' release of vorbis; I see a lot of messages floating around as 'now 1.0, and -soon- it will include joint-stereo, Wavelets, low-bitrate, peeling, etc. etc.' Before I start 'advocating' vorbis and tell everybody what it all can do; is there actually a date or some other planning when all those

Hi Farhan, My mistake, it is 9.6kps because is on gsm ! Regards, Danny -----Original Message----- From: speex-dev-bounces@xiph.org [mailto:speex-dev-bounces@xiph.org] On Behalf Of Danny Chan Sent: Friday, November 19, 2004 2:08 AM To: Ashhar Farhan; speex Subject: RE: [Speex-dev] jitter buffer Hi Farhan, It is interesting that GPRS is 9.6 kps, as per GPRS standard it should be 115kps ? if

Hi Farhan, It is interesting that GPRS is 9.6 kps, as per GPRS standard it should be 115kps ? if it is 9.6kps is true then I would use speex codec on GPRS for my project, since in some country they charge GPRS on flat rate rather than expensive airtime. Thanks for your work ! Regards Danny -----Original Message----- From: speex-dev-bounces@xiph.org [mailto:speex-dev-bounces@xiph.org] On

Any have any success using a patton smartnode 4118/js/eiu fxs gateway with asterisk? We we're able to get the unit to register with asterisk, but when trying to place a call, no codec was compatible, even though I had all of the following enabled on the patton ... # G.711 A-Law/?-Law (64kbps) # G.726 (ADPCM 40, 32, 24, 16 kpbs) # G.723.1 (5.3 or 6.3 kbps) # G.729ab (8kbps) the link to this

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

>> FYI: The below is just my interpretation of the code, I might be wrong. > > Most of it is right. Actually, would you mind if I use part of your > email for documenting the jitter buffer in the manual? It would be my pleasure :) >> early_ratio_XX is the sum of all the positive bins. >> late_ratio_XX is the sum of all the negative bins. > > Right. And only the

On Sun, 2003-11-23 at 03:51, Kerry Cox wrote: > Hmmm, I guess more is incorrect here than I thought. I changed the > resample in-rate to be 44100 like it should have have been. > But still no joy. Here is the error message as shown in the error.log > file. I'm looking things over and am not seeing my error. > It looks like the audio resample for this particular stream is good.

Coming out of a long (but definately needed) silence for a moment: A few things for vorbis-tools, since I no longer have CVS access (I think I just misplaced that key): 1. Before anything, put oggchain out of its misery. Please. It's a pile of junk that should have never been committed. Any smidgen of usefulness from it belongs in ogginfo anyway (and it's already there). 2. ./autogen.sh

Tim, et al, I have run into several problems with V0.8.0. I will address them seperately. 1. My compiler is complaining about the following code in celt.c which seems to define metric first as celt_word32, then as celt_word16. Am I mis-interpreting something? ?? VARDECL(celt_word32, metric); ?? ALLOC(metric, len, celt_word16); Thx MikeH -------------- next part -------------- An HTML attachment

Thank you for a very good explanation which shed light on some of the questions that I had after reading the source code. Reading your text however, I wonder if I'm perhaps missing an important point on the proper use of the jitter buffer: ... > Now, clearly, if early_ratio is high and late_ratio is very > low, the buffer is buffering more than it needs to; it will > skip a frame

Hi all: How to use jitter.c, I see this file is not include in the lib. Sorry for this newbie Q.