search for: jitter_buffer_get

Hi ! I am working with the speex client example which is on http://svn.xiph.org/trunk/speex/speexclient/ and it does not seem to work out of the box for me. I am always getting this warning messages: warning: jitter_buffer_get() : packet too large to fit. Size is 70. Do you have any idea of why this might be happening ? Thanks in advance, Lorenzo Fundar? Garc?a Universit? de Technologie de Compi?gne G?nie Informatique -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org...

...t it seems to work. Hmm, I always assumed there wouldn't be any overflows. What parameter range are you using that causes them? I can always switch to 32-bit, but I prefer 16-bit for memory size reasons (I'll switch if there's no other option). > But now I have another question. If jitter_buffer_get returns > JITTER_BUFFER_INSERTION or JITTER_BUFFER_MISSING, packet->span can be > larger than desired_span or the normal packets' span. Must the > application take this into account? If so, speex_jitter_buffer does > not handle this correctly at the moment. Well, you can choose...

...questions. 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? Correspondingly, how is the internal JitterBuffer state affected by calling jitter_buffer_get (and _tick) before jitter_buffer_put has a chance to deliver the first packet of a stream? Should this be avoided? jitter_buffer_get can return JITTER_BUFFER_INSERTION and JITTER_BUFFER_MISSING. In both situations speex_jitter_buffer.c makes the codec interpolate a frame. How are these condi...

...of 48khz the normal jitter could sometimes exceed +-32k in my opinion. Therefore I thought using spx_int32_t was the simplest solution. But of course you can alternatively check for overflows in shift_timings as it's already done in update_timings. > > But now I have another question. If jitter_buffer_get returns > > JITTER_BUFFER_INSERTION or JITTER_BUFFER_MISSING, packet->span can be > > larger than desired_span or the normal packets' span. Must the > > application take this into account? If so, speex_jitter_buffer does > > not handle this correctly at the moment. &g...

...imestamp of arriving audio frames will be in multiples of 160. If a frame (or more frames) arrives from the remote side inside a RTP packet, I invoke jitter_buffer_put() successively on the received frames, right? If my audio output stream runs out of data and requires new frame to play, I invoke jitter_buffer_get(), right? The questions that I have are: - what does the method jitter_buffer_get() return when it has no frame? JITTER_BUFFER_MISSING? In this case, should I say "no data" to the audio output stream? - what does it mean when jitter_buffer_get() returns JITTER_BUFFER_INSERTION? The comme...

...gt; 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() right after the call go jitter_buffer_get() Let me know if it doesn't work (and be more precise as to what doesn't work). Jean-Marc

...y 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() > right after the call go jitter_buffer_get() > > Let me know if it doesn't work (and be more precise as to what doesn't > work). > > Jean-Marc > > >

...ut(m_JitterBuffer, &p); } m_Mutex.Release(); delete packet; } void BeatJitterBuffer::GetSound(char* buffer, size_t maxLength) { int ret; if (320 == maxLength) { JitterBufferPacket packet; packet.data = buffer; m_Mutex.Aquire(); ret = jitter_buffer_get(m_JitterBuffer, &packet, 0); if(ret != JITTER_BUFFER_OK) { ZeroMemory(packet.data, maxLength); } jitter_buffer_tick(m_JitterBuffer); jitter_buffer_update_delay(m_JitterBuffer, &packet, NULL); m_Mutex.Release(); } else...

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:

Hi, I'd like to report a bug in speexclient/speex_jitter_buffer.c. In the function speex_jitter_get(), after the line: packet.data = data; add the line packet.len = 2048; If this variable is uninitialized, then in jitter_buffer_get() (in jitter.c), the predicate "jitter->packets[i].len > packet->len" is undetermined. When this happens, the wrong amount of data is copied from the jitter-buffer (eg: if (packet->len == 0), then no data is copied). For some reason, this didn't bite me on OS X, but when...

...packet. That way, it finds the packet, decodes the first frame it contains, and keeps the rest for the next time. If you only use one frame per packet (which most people do), it's not necessary to do that. > Correspondingly, how is the internal JitterBuffer state affected by > calling jitter_buffer_get (and _tick) before jitter_buffer_put has a > chance to deliver the first packet of a stream? Should this be avoided? At this point, this should probably be avoided (I've heard of problems when doing that), but eventually this is a case the jitter buffer should be able to handle. > jit...

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 because jitter_buffer_get iteration return this warning. thanks Luca

...tJitterBuffer::GetSound(char* buffer, size_t maxLength) >> { >> int ret; >> >> if (320 == maxLength) >> { >> JitterBufferPacket packet; >> packet.data = buffer; >> >> m_Mutex.Aquire(); >> >> ret = jitter_buffer_get(m_JitterBuffer, &packet, 0); >> >> if(ret != JITTER_BUFFER_OK) >> { >> ZeroMemory(packet.data, maxLength); >> } >> >> jitter_buffer_tick(m_JitterBuffer); >> jitter_buffer_update_delay(m_JitterBuffer,...

...esn'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() >> right after the call go jitter_buffer_get() >> >> Let me know if it doesn't work (and be more precise as to what doesn't >> work). >> >> Jean-Marc >> >> >> > > _______________________________________________ > Speex-dev mailing list > Speex-dev@xiph.org > http://lists...

...delete packet; > } > > void BeatJitterBuffer::GetSound(char* buffer, size_t maxLength) > { > int ret; > > if (320 == maxLength) > { > JitterBufferPacket packet; > packet.data = buffer; > > m_Mutex.Aquire(); > > ret = jitter_buffer_get(m_JitterBuffer, &packet, 0); > > if(ret != JITTER_BUFFER_OK) > { > ZeroMemory(packet.data, maxLength); > } > > jitter_buffer_tick(m_JitterBuffer); > jitter_buffer_update_delay(m_JitterBuffer, &packet, NULL); >...

...maxLength) >>> { >>> int ret; >>> >>> if (320 == maxLength) >>> { >>> JitterBufferPacket packet; >>> packet.data = buffer; >>> >>> m_Mutex.Aquire(); >>> >>> ret = jitter_buffer_get(m_JitterBuffer, &packet, 0); >>> >>> if(ret != JITTER_BUFFER_OK) >>> { >>> ZeroMemory(packet.data, maxLength); >>> } >>> >>> jitter_buffer_tick(m_JitterBuffer); >>> jitter_buff...

.... I have run into some issues when using it. My first problem is minor with jitter_buffer_init(int step_size). The initialization of buffer_margin I think this should be 1 not 0. /*FIXME: Should this be 0 or 1?*/ jitter->buffer_margin = 0; With it set to 0 there is a problem if jitter_buffer_get() is called before jitter_buffer_put(). This cause all packets to be discarded due to every new packet being late. With jitter->buffer_margin = 1; there is no problem with the calling order. My second problem happens when there is a dropout in the connection. If the packets are postponed during...

...into the jitter buffer */ -void jitter_buffer_put(JitterBuffer *jitter, const JitterBufferPacket *packet) +EXPORT void jitter_buffer_put(JitterBuffer *jitter, const JitterBufferPacket *packet) { int i,j; int late; @@ -459,7 +459,7 @@ } /** Get one packet from the jitter buffer */ -int jitter_buffer_get(JitterBuffer *jitter, JitterBufferPacket *packet, spx_int32_t desired_span, spx_int32_t *start_offset) +EXPORT int jitter_buffer_get(JitterBuffer *jitter, JitterBufferPacket *packet, spx_int32_t desired_span, spx_int32_t *start_offset) { int i; unsigned int j; @@ -674,7 +674,7 @@ } -i...

...into the jitter buffer */ -void jitter_buffer_put(JitterBuffer *jitter, const JitterBufferPacket *packet) +EXPORT void jitter_buffer_put(JitterBuffer *jitter, const JitterBufferPacket *packet) { int i,j; int late; @@ -459,7 +459,7 @@ } /** Get one packet from the jitter buffer */ -int jitter_buffer_get(JitterBuffer *jitter, JitterBufferPacket *packet, spx_int32_t desired_span, spx_int32_t *start_offset) +EXPORT int jitter_buffer_get(JitterBuffer *jitter, JitterBufferPacket *packet, spx_int32_t desired_span, spx_int32_t *start_offset) { int i; unsigned int j; @@ -674,7 +674,7 @@ } -i...