similar to: The generic Jitter Buffer and its use

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

Hi Zachary, Zachary Schneirov a ?crit : > The speex_jitter_buffer.c wrapper seems to maintain (buffer?) one > packet-frame ("current_packet") in addition to the packets already > tracked by the JitterBuffer itself. Why is this necessary? That's in case there's more than one frame per packet. That way, it finds the packet, decodes the first frame it contains, and

Hello Jean-Marc, thank you for your reply. > > I found the cause of the problem. The function shift_timings can > > produce overflows in the timing array if the jitter is huge or the > > time units are very short. After changing the timing values' type from > > spx_int16_t to spx_int32_t it seems to work. > Hmm, I always assumed there wouldn't be any overflows.

Daniel Schmidt a ?crit : > I found the cause of the problem. The function shift_timings can > produce overflows in the timing array if the jitter is huge or the > time units are very short. After changing the timing values' type from > spx_int16_t to spx_int32_t it seems to work. Hmm, I always assumed there wouldn't be any overflows. What parameter range are you using that

(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

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

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

I am trying to using Speex for some Wireless voice transfers. I am using the 8K narrow band but am feeding it 11025 sample rate. Each Speex frame is about 14.5ms instead of 20ms. In order to minimize WiFi packet traffic I am sending 7 Speex frames at a time for a packet rate of about 10 per second so each WiFi packet has about 101ms of voice data. I have three modes 1. Simplex - voice messaging

Hi, The Speex bit-packer already does everything you need. Just call speex_encode() multiple times to encode multiple frames and call speex_decode() multiple times to decode these frames. Jean-Marc Quoting Marian Kechlibar <marian.kechlibar at circletech.net>: > Hello all, > > I am experimenting with Speex in a mobile VoIP application, and it seems > that it is worth

Hello all, I am experimenting with Speex in a mobile VoIP application, and it seems that it is worth stuffing more than one codec frame into a single RTP packet; mainly, that sending several frames per packet relieves the underlying network socket connection, which is notoriously problematic in mobile devices. RFC 5574 defines the exact way how to put multiple Speex frames into a single RTP

Hi Marian, I took a brief look at RFC 5574 and as far as I understand, you can simply do it like this: SpeexBits b; speex_encode(state, some320bytePCM1, &b); speex_encode(state, some320bytePCM2, &b); After that, get the encoded data with speex_bits_write and put it in your packet. Mark -----Original Message----- From: speex-dev-bounces at xiph.org [mailto:speex-dev-bounces at

Jean-Marc Valin wrote: >>In particular, (I'm not really sure, because I don't thorougly >>understand it yet) I don't think your jitterbuffer handles: >> >>DTX: discontinuous transmission. >> >> > >That is dealt with by the codec, at least for Speex. When it stops >receiving packets, it already knows whether it's in DTX/CNG mode.

> In particular, (I'm not really sure, because I don't thorougly > understand it yet) I don't think your jitterbuffer handles: > > DTX: discontinuous transmission. That is dealt with by the codec, at least for Speex. When it stops receiving packets, it already knows whether it's in DTX/CNG mode. > clock skew: (see discussion, though) Clock skew is one of the main

Hi... I'm trying the adaptative jitter buffer of Speex. Anyone can help me? I don't understand because my application manytimes return "warning: jitter_buffer_get(): packet too large to fit. Size is " I test my program over local cable net and i think that is impossible have packet lost or corruption. I've looked the source but i don't undestand what happen and

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 Conrad, Thanks a lot for the info. This is exactly what I needed. We want to use speex in our IP telephony client and I was indeed trying to put together a GUI configuration screen. Best regards, Chris > On Tue, May 20, 2003 at 06:04:39PM +0200, Chris Flerackers wrote: >> Hi, >> >> Is there are document where the interaction between all the configuration >> options

Hi, I've attached a patch against SVN r14645 which adds GCC visibility information to all symbols exported from libspeex.so and libspeexdsp.so. It includes a configure.ac change to test that both the compiler flags and __attribute__((visibility)) works, and if so will #define EXPORT __attribute__((visibility("default"))) and if not #define EXPORT I've attached a diff output

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, I've attached a patch against SVN r14645 which adds GCC visibility information to all symbols exported from libspeex.so and libspeexdsp.so. It includes a configure.ac change to test that both the compiler flags and __attribute__((visibility)) works, and if so will #define EXPORT __attribute__((visibility("default"))) and if not #define EXPORT I've attached a diff output