similar to: Who is using the jitter buffer?

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

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

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

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

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

> 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

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

Patch applied offline (I'm in the plane), remind me if I forget to push it. About the "resync on burst" issue, I was aware of it, but I'm not sure how to fix it. Any idea? Also, do you see the problem happening often? Jean-Marc Thorvald Natvig a ?crit : > > The jitter buffer would "freeze" under the following condition: > > - The sender and receiver are

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

Jean-Marc Valin wrote: > Thorvald Natvig a ?crit : > >> 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) >> > > While I'm not completely done yet, I thought the current version was > working. Can you tell

But that's what a jitter buffer will do, eventually - drop a packet. And it's better to drop a silence packet. Cheers, .a -----Original Message----- From: Jean-Marc Valin [mailto:jean-marc.valin@usherbrooke.ca] Sent: Wednesday, December 21, 2005 3:39 PM To: Alex Bakaev Cc: Shantanu Gramsci; speex-dev@xiph.org Subject: RE: [Speex-dev] Bitrate problem On Wed, 2005-12-21 at 15:29 -0800,

> 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

Le mardi 02 mai 2006 ? 18:15 +0200, Thorvald Natvig a ?crit : > 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_*). Oops, I forgot to make sure I keep the API stable for the old buffer. Any thoughts on

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

> Hi, > > It could (and should) definitely be done, but it's somewhere > (unfortunately not on top) on my TODO list. I think the simplest way > (until I really integrate the preprocessor with the codec, which will > take a while) to do it is to add a speex_encoder_ctl() call as you > proposed. I'd call it SPEEX_SET_EXT_VAD_STATUS and I'm willing to merge > a

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

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

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

pwk.linuxfan@gmx.de wrote: > On Sunday 08 July 2007 02:24, Thorvald Natvig wrote: > >> Next, and slightly unrelated question: >> Why does >> int jitter_buffer_update_delay(JitterBuffer *jitter, JitterBufferPacket >> *packet, spx_int32_t *start_offset); >> include the packet parameter? It's not used in the code, and it also >> makes the API slightly