similar to: Changing the meaning of jitter buffer timestamp

> what happens if this number flows over? It is just a "int", so it might reach > its limits at 2^15 = 32768, that happens after 102 puts... I would say that an int is 32 bits :-) Actually, RTP defines the timestamp as a 32-bit value. Now, what happens when it overflows (3 days for narrowband), I don't know what the RFC says about it. > In my current > implementation

On Saturday 01 October 2005 09:19, Jean-Marc Valin wrote: > 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

On Wednesday 05 October 2005 13:53, Jean-Marc Valin wrote: > > what happens if this number flows over? It is just a "int", so it might > > reach its limits at 2^15 = 32768, that happens after 102 puts... > > I would say that an int is 32 bits :-) Actually, RTP defines the > timestamp as a 32-bit value. Now, what happens when it overflows (3 days > for narrowband),

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

> My C book taught me an int is only guaranteed to be 16bits or bigger, and > since I am trying to write code that doesn't break on other systems, I am > assuming the "worst case". Hence I have to deal with the overflow... Is my > information that "int" can be 16bit (a) false or (b) true but not valid for > any relevant architecture? c) assumes that I

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

Hi, Is there an easy way to get the size in samples of a Speex packet, without decoding the packet? If I receive a "narrowband packet" with - Zero or more wideband frames (must be skipped apparently) - Zero or more Speex inband requests - Zero or more user inband requests - One or more narrowband frames I need to know how much samples the packet contains to calculate jitter buffer

Hi Steve, Steve Kann wrote: > Chris Flerackers wrote: >> Hi, >> >> Is there an easy way to get the size in samples of a Speex packet, >> without decoding the packet? >> >> If I receive a "narrowband packet" with >> - Zero or more wideband frames (must be skipped apparently) >> - Zero or more Speex inband requests >> - Zero or

> 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

Hi, We've been having mixed success (mostly good) with the jitter-buffer, and I'm trying to understand what my options are for tuning JB parameters to our particular use-case. In what may become a series of emails, my first question is how to properly set the margin parameter. I have set up a test harness that allows me to synthesize arbitrary sequences of puts/gets, so that I can test

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

> 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

Dear Speex developers, I am currently experimenting with Speex on Symbian smartphones. I have compiled the Speex library, and I am now using it in the following way: 1. Record 320-byte buffers of data in PCM16 format, 8000 Hz sampling rate. 2. Feed the resulting buffer to an instance of a narrowband Speex encoder. 3. Send the encoded data over RTP. 4. Upon receiving on the other side, feed the

> 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

--- Jean-Marc Valin <jean-marc.valin@usherbrooke.ca> wrote: > > Sorry if this a repost but I want to create the > > smallest Speex library possible to be put in TI's > > TMS320 DSP. I'm only interested in one > configuration: > > 5.97 Kbps narrowband. What part of source code > can I > > remove? Currently, when I compiled the version >

We have a customer who is connected to our PSTN gateway using IAX and noticing that even when the traffic from their site is modest their outbound audio has short dropouts. Inbound audio is fine. (They have ADSL so it is expected that outbound audio would be the first to experience problems.) We have several questions to pose to the collective wisdom of this list. Q1: Are there any statistics

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, Sorry if this a repost but I want to create the smallest Speex library possible to be put in TI's TMS320 DSP. I'm only interested in one configuration: 5.97 Kbps narrowband. What part of source code can I remove? Currently, when I compiled the version 1.1.12 libspeex.a library with the TI TMS320 and Fixed-Integer options, I get around 522Kb. I would like to reduce it to as small

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

I've been trying to resolve some quality issues and I was hoping someone might be able to provide some insight. To give you an idea the calls are coming in via a SIP DID and sent out via an IAX2 connection. Latency to both the SIP equipment and IAX equipment are around 80ms with 0 packet loss accoridng to ping tests. The server is located in a data centre so bandwidth is not an issue. Most