similar to: Jitter buffer

Danny Chan wrote: >Hi Jean and Steve, > >Can you tell me whether the jitter filter / buffer is adaptive type, I >saw the description of speex_jitter.h say it is "adaptive", anyone of >the group has implemented it and confirm it. > > I believe it is adaptive, but no, I haven't used it, because it's coupled only to the speex codec. We're working on a

Hmm, I tried... I completly understand an idea of jitter buffer and I know there is a lot of kinds of this solution (eg. AJB - Adaptive Jitter Buffer). I simply want to know what type is used in speex codec and how could I use that. What is the reason for using jitter buffer implemented in speex against to my own (implemented at lower layer - transmission layer - eg. rtp). Kapul On Tue, Sep

Hello, I've only one question: how does a jitter buffer work? Regards Kapul

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

Jean-Marc Valin wrote: >>I believe it is adaptive, but no, I haven't used it, because it's >>coupled only to the speex codec. We're working on a generic >>application and codec-independent jitter buffer algorithm, for use in >>asterisk and iaxclient (at least). Some information is available at

> I believe it is adaptive, but no, I haven't used it, because it's > coupled only to the speex codec. We're working on a generic > application and codec-independent jitter buffer algorithm, for use in > asterisk and iaxclient (at least). Some information is available at > http://www.voip-info.org/tiki-index.php?page=Asterisk%20new% > 20jitterbuffer Yes, this

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:

> Yes. Jean-Marc has made the API more similar. > > Jean-Marc: Have you looked at the API we have for the > asterisk/iaxclient jitterbuffer? Just did. > It's pretty close to what you have now -- the major difference is that > your jb still assumes it can "own" the data passed in -- it copies it, > and it destroys it at will. With the API I put together,

On 5/3/06, Jean-Marc Valin <Jean-Marc.Valin@usherbrooke.ca> wrote: > > I must say I really like the generalized jitter buffer though :) It's a > > cleaner and more flexible implementation and can more easily be adjusted > > to contain additional information with each packet. This looks interesting to tie into asterisk's jb and plc code as well.

Dear speex developers and users, I'm considering adopting the speex jitter buffer for use with a different codec in a voice conferencing system and would be very grateful if those more acquainted with it could help me with some questions. The speex_jitter_buffer.c wrapper seems to maintain (buffer?) one packet-frame ("current_packet") in addition to the packets already

I'm assuming asterisk does not have a SIP jitter buffer in place? Any ideas on how to help with this going over a data T1 where VoIP is shared with regular traffic? Problem is when people are downloading the voice is jittery, even lossy. Matt

Hi, Ok, what you suggest sound logical to me. Currently, I have done a small trick to prevent this problem. What I did is that whenever windows request a voice packet from me and if I do not have the voice packet, I repeat the previous packet. Hence, all the breaking portion is filled with previous packet. This trick seems to work so far. I am not sure what is the side effect. I think jitter

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

> We just return a frame with the return value JB_DROP, which tells the > caller to drop this frame, and call jb_get again. > > When the caller is done with the jitterbuffer, it calls jb_getall() > repeatedly, until it's empty, and then it can discard all the frames. Hmm, looks a bit error-prone to me. Especially considering I still have to explain that "no, you

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

Ok, this is a silly question, but what does the jitter buffer do? I'm really new to audio, so please bear with me. From what I gather (primarily from the list archive), the jitter buffer is a wrapper around the Speex decoder. I give it the packets I receive, in whatever order I receive them, and then it gives me back a clean stream of audio samples. But what I don't entirely

Hello, I understand that only the destination of a call should do jitter buffering. So, if IAX2/PhoneA calls IAX2/PhoneB through my server (no transfers), PhoneA and PhoneB need to perform their own jitter buffering, and Asterisk will just forward the frames, correct? What happens if the peer does not support jitter buffering, but is close by so there's no need for jitter buffering? My

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

What is the best way to pick a prebuffering length for a streaming audio application using UDP transport? I'm using Speex in a VoIP application with RTP transport, currently with a fixed 500ms prebuffer on the playback side. However, I'd like something a bit more adaptive to accomodate high-jitter connections. For example, in one test configuration there is a very low average

Hi everyone, Judging from the lack of complaints about the split, I think I can go safely forward with that. The only thing to decide is the name of the new library that will contain the preprocessor, the AEC, jitter buffer, and resampler. So far, I've got a few potential names: - libspeaks - libspeexproc - libspeexvoip - libspeech - libspoke Let me know (in private so as to not flood the