search for: speex_jitter_put

...re correct way to > solve > > this problem but I think this is not so easy. Is > there > > got any source code to reference from? > > Look for the speex_jitter.h header. I tried to implement it but I don't really understand the parameters for the speex_jitter_get() and speex_jitter_put() function. I have the following questions: Since the second parameter of speex_jitter_put() is a char* and the second parameter of speex_jitter_get() is a short*, does it mean that these two function will actually replace speex_bits_read_from() and speex_decode_int()? Also, which timestamp sh...

...fering more than it needs to; it will >> skip a frame to reduce latency. > ... > > Question: > Do I understand it that I should not put every incoming packet through the > jitter buffer? > > The way my code works today is: > > 1) Packet read from socket > 2) Call speex_jitter_put(...) with the just-arrived packet > 3) Read one packet from jitter buffer using speex_jitter_get(...) function > 4) Feed just read-from-jitter packet to the sound card for playback > > This will in fact feed one 20msec batch of sound to play at the sound card > for every packet recei...

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: http://lists.xiph.org/pipermail/spe...

...nd late_ratio is very > low, the buffer is buffering more than it needs to; it will > skip a frame to reduce latency. ... Question: Do I understand it that I should not put every incoming packet through the jitter buffer? The way my code works today is: 1) Packet read from socket 2) Call speex_jitter_put(...) with the just-arrived packet 3) Read one packet from jitter buffer using speex_jitter_get(...) function 4) Feed just read-from-jitter packet to the sound card for playback This will in fact feed one 20msec batch of sound to play at the sound card for every packet received from the speex encod...

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

...ge----- 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. > > 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. I recently made a few changes to the jitter buffer. Could you add a call to: jitter_buffer_update_delay()...

...fering more than it needs to; it will >> skip a frame to reduce latency. > ... > > Question: > Do I understand it that I should not put every incoming packet through the > jitter buffer? > > The way my code works today is: > > 1) Packet read from socket > 2) Call speex_jitter_put(...) with the just-arrived packet > 3) Read one packet from jitter buffer using speex_jitter_get(...) function > 4) Feed just read-from-jitter packet to the sound card for playback > > This will in fact feed one 20msec batch of sound to play at the sound card > for every packet recei...

...o: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. >> >> 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. > > I recently made a few changes to the jitter buffer. Could you add a call...

...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 data]. 2) The receiver would receive UDP data and call speex_jitter_put(...) for each packet received. 3) The decoder would call speex_jitter_get(...) to get the next packet to decode and play. Far off, or close to how the big boys would do it? Any information is greatly appreciated. Respectfully, Baldvin -------------- next part -------------- An HTML attachme...

...nt len=(audio_page.body_len-4)/FRAMES_PACKET; char *datos=(char*)op.packet; char m[100]; sprintf(m,"paq %d",op.packetno); System::Console::WriteLine(gcnew String(m)); int t=((int *)datos)[0]; for(int i=0;i<FRAMES_PACKET;i++) speex_jitter_put(&jitter,(datos+4)+len*i,len,t+FRAME_SIZE*i); } } -- http://www.apple.com A veces me da por ahi. Otras como que no. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/speex-dev/attachments/20060807/88642a6c/attachment.html

...he packet is "hopelessly late". If lost_count > 20, something is very wrong and we want this packet to be the start of our new synchronized stream. Also included is a testcase. Note that I found a related problem if the receiver is frozen. Once it unfreezes, you may have a hundred speex_jitter_put before a _get. _get will then still return the very first packet, even if there are suddenly 100 unplayed packets in the buffer (so it's playing old data). Similarily, if more than 300 packets are suddenly inserted, the buffer is full, and the call to _get actually fails, even if there are...

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

...38 when it is in silence. But In other computers the same code return 1. After I add the function speex_preprocess(), speex_bits_write() return 1 when it is silence in all computers. Besides, I found another problem. I enabled VAD and DTX. I called speex_preprocess() before speex_encode(). I used speex_jitter_put() and speex_jitter_get() to decode. When I played the voice data after I call speex_jitter_get(), I can hear nothing. The sound disappeared. Thanks Jonathan <p>--- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from thi...

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

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 the change (revert or continue as is)? > However, a lot of > warning: did...

...> > char *datos=(char*)op.packet; > char m[100]; > sprintf(m,"paq %d", op.packetno); > System::Console::WriteLine(gcnew String(m)); > > int t=((int *)datos)[0]; > for(int i=0;i<FRAMES_PACKET;i++) > speex_jitter_put(&jitter,(datos+4)+len*i,len,t > +FRAME_SIZE*i); > } > } > > > -- > http://www.apple.com > A veces me da por ahi. Otras como que no. > _______________________________________________ > Speex-dev mailing list > Speex-dev@xiph.org > http://lists.xiph.or...

...a] >> 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. >>> >>> 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. >> I recently made a few changes to the jitter bu...

...ly late". If lost_count > 20, something is very wrong > and we want this packet to be the start of our new synchronized stream. > > Also included is a testcase. > > Note that I found a related problem if the receiver is frozen. Once it > unfreezes, you may have a hundred speex_jitter_put before a _get. _get > will then still return the very first packet, even if there are suddenly > 100 unplayed packets in the buffer (so it's playing old data). > Similarily, if more than 300 packets are suddenly inserted, the buffer > is full, and the call to _get actually fails, ev...

>> 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 presume the ide...