similar to: Jitter buffer usage

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

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:

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

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

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

[The following is perhaps a long question and even off-speex topic,] [but if anyone can at least point me in the right direction for ] [alternate sources of information, I'd really appreciate it. ] When speex_jitter_get(...) is called and there is no buffer/data to return, would I not want to know that there is no true data to play? If I turn around and queue 20ms of silence to play

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:

> 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

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

Good question. I'm coming to the conclusion that using plain UDP and "home-grown" packet construction for transmitting the speex data (with timestamp/sequence counter) and implementing jitter control on the receiver end is an adequate implementation for a VoIP application. Assuming of course that I don't care about any interoperability issues with other applications etc. I was

Hi Ouss, Can you test again? I think I found and fixed the problem. Jean-Marc Ouss a ?crit : > 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 > > >

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

>> 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 the change (revert or continue as is)? Well, I

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

Hi. I'd like to get access to the CDR's generated by Asterisk (1.4) in real-time from a remote connection coming in on TCP. Basically what I have is a Windows application that is used to process incoming, outgoing and missed call records putting them into a database for some analysing etc. This app can connect to a TCP server and read from this connection the CDR's as they are

The jitter buffer would "freeze" under the following condition: - The sender and receiver are in sync. - The sender machine freezes for a few seconds while the receiver does not. - This causes all the packets sent by the sender to have a timestamp that is too low to be considered, meaning jitter_buffer_put ditches it before it checks if lost_count > 20 to reset. - The jitter buffer

Hello. I am looking for details of the maximum allowed/usable/effective wire/cable length of the connection from a FXS port of Digium analog cards to the analog telephone handset. To clarify my intention, I need to have an analog telephone connection to my asterisk box that is 3000 meters (3km) away at least. If you have any details of ATA boxes or other similar devices that I could use to

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

I've looked around and not found details on the expected frequency range the Speex codec can be expected to carry. Is there any documentation available or a table of some sort that has been compiled which would give an indication of the frequency range based on the various compression options in speex? Best regards, Baldvin Hansson Reykjavik, Iceland baldvin@baldvin.com -------------- next