similar to: Jitter Buffer fix for frozen sender

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, I am using the JitterBuffer. Since there is not so much documentation I think I dont use it in a correct way. All the packets are recieved (I control the sequence numbers) but the JitterBuffer often tells me he has no packet. I am using it in the following way: I am not sure if I use the ticks correctly but I think it can be set to 20(msec). It is set as a Member in my class and i

Thanks for your reply Jean-Marc! this was what I had before. But I decided to restructure it since the thread that plays the sound is a callback from the sound hardware, more or less an interrupt handler. For me it seems more reasonable to waste some memory for to save the decompressed Packet. While I write this I begin to think that it is possible I decompress Packets that are never used

Hello, I think that the new Jitter Buffer have a problem. It works perfectly when I call the speex_jitter_put every 20ms (on my lan) but in other case (with big latency on Internet connexion), it doesn't works. The old version is OK in all cases. Hope it will helps. Thanks Ouss -------------- next part -------------- An HTML attachment was scrubbed... URL:

I use the speex version of your jitter, and in speex_jitter_get, you always call the jitter_buffer_update_delay. -----Original Message----- From: Jean-Marc Valin [mailto:jean-marc.valin@usherbrooke.ca] Sent: dimanche 18 mars 2007 13:06 To: Ouss Cc: speex-dev@xiph.org Subject: Re: [Speex-dev] Problem with the svn jitter buffer > I think that the new Jitter Buffer have a problem. > >

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. 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_*). However, a lot of warning: did you forget to call jitter_buffer_tick() by any chance? is displayed. Looking at speex_jitter_get, the logic seems to be as follows: if

Since r12660, the speex_jitter_get with high latency doesn?t works, I have no sound. Before this release, the speex_jitter_get works in all conditions. speex_jitter_get return void, then I cannot know the reason of this problem. Regards Ouss -----Original Message----- From: Jean-Marc Valin [mailto:jean-marc.valin@usherbrooke.ca] Sent: dimanche 18 mars 2007 23:07 To: Ouss Cc:

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

Dear all. Questions regarding VoIP implementation and the use of the Speex jitter buffer, if I may: Am I right in my understanding that the Speex jitter buffer implementation is used only on the receiving end of a network VoIP stream? 1) The sender would sample+encode+timestamp packets/frames of speex data and send via UDP to receiver. UDP packet would be constructed as: [TIMESTAMP][Speex

('binary' encoding is not supported, stored as-is) I'm working on a voip project with Speex and the only major design obstacle left (that I'm aware of) is the jitter buffer. Before I attempt to write something of my own I'd like to try out the jitter buffer functions in Speex's unstable release. Can anyone give me a basic run down of how the experimental jitter buffer is

> (PS, if you do use threads, protect speex_jitter_put/get with a mutex > (CRITICAL_SECTION I believe they're called in Win32Speak) -- calling put > and get at the exact same time from different threads leads to "features") I've never tested this, but I designed the jitter buffer to work from two threads even without using a mutex. This would work as long as there is

> 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 Jean, > Actually, Speex has Packet Loss Concealment (PLC) > builtin. If a packet > is missing, instead of repeating the previous one, > just try decoding by > passing NULL instead of the SpeexBits struct. > Thanks, I have made the above changes and the effect seems to be better now. > > I think jitter buffering is more correct way to > solve > > this problem

> 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

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

(Sorry about the delay -- currently attending ICASSP) Hi, Haven't looked at all the details, but what's clearly wrong is that you need to put the *compressed* packets in the jitter buffer and decode them only when you _get() them. Jean-Marc David Feurle wrote: > Hi, > > I am using the JitterBuffer. Since there is not so much documentation I > think I dont use it in a

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

There is an error in the manual as it is now on p.39 (speex-manual.pdf)?under the speex specific jitter buffer. The error was also a part of the code untill resently (I downloaded it a few weeks ago with the error) ? The error was (in the code) in the function: voidspeex_jitter_get(,,) where the packet.len was not set to 2048. So actually there should just be inserted the statement: packet.len =

David Feurle wrote: > Thanks for your reply Jean-Marc! > > this was what I had before. > But I decided to restructure it since the thread that plays the sound is > a callback from the sound hardware, more or less an interrupt handler. > For me it seems more reasonable to waste some memory for to save the > decompressed Packet. While I write this I begin to think that it is