search for: speex_jitter_buffer

Hi, I have a few questions about the speex_jitter_buffer when used with DTX here goes: I want to use the speex_jitter_buffer with muliple streams (multi client) and with DTX so that clients will only transmit data when they are actually saying anything, but Im unsure of how the ticking is handled. I have 1 x SpeexJitter struct per client stream...

Hi, It seems like there's a missing ... #ifdef __cplusplus extern "C" { #endif ... somewhere near the beginning of speex_jitter_buffer.h (I'm looking at the latest SVN version). Otherwise, there is nothing to match the "#ifdef __cplusplus" near the end of the file. Inserting the lines above allows my code to compile. (BTW, Speex has been working like a charm for us! Thanks!) Cheers, Josh -------------- nex...

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

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

...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 the size of the insertions or concealment, so I'm not sure what's the problem. The app definitely needs to use the returned span correctly. Jean-Marc > Best regards, > Daniel > > P.S. We can move this c...

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

...date_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. > Well, you can choose the size of the insertions or concealment, so I'm > not sure what's the problem. The app definitely needs to use the > returned span correctly. The speex_jitter_buffer presented in the manual and used b...

...se. Googling the subject I've find that there are, or there were, two jitter buffers, a generic one and a speex-specific one, is this still true or they've been joined? Downloading the 1.2rc1 source code there's no trace of the SpeexJitter structure and wrapper functions included in the speex_jitter_buffer.h / speex_jitter_buffer.c, are these files obsolete? Do I have to directly use the functions that start with jitter_buffer_? The second question is related to the timestamp and the packet span. I'd use with nb decoder 160 for the span but, what about the timestamps? Somewhere I've read that...