similar to: Jitter buffer (speex_jitter.h) usage

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

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

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

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.

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

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

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:

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:

Hello all, I am currently investigating the JitterBuffer struct provided in the Speex library, and I am actually thinking about using it with two different codecs: namely, Speex-NB and AMR-NB. From looking at the code, it seems that JitterBuffer is capable of working for any codec. Both Speex-NB and AMR-NB (and probably also other narrowband codecs) produce 20 ms frames and the sampling frequency

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

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

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 Im using portaudio and Im planning on

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

(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

pwk.linuxfan@gmx.de wrote: > On Sunday 08 July 2007 02:24, Thorvald Natvig wrote: > >> Next, and slightly unrelated question: >> Why does >> int jitter_buffer_update_delay(JitterBuffer *jitter, JitterBufferPacket >> *packet, spx_int32_t *start_offset); >> include the packet parameter? It's not used in the code, and it also >> makes the API slightly

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'm moving my "metadata" which accompanies some of the speech packets into the speex bits. However, as usual, I'm a bit confused. The manual (PDF from current SVN), section 5.10 (bottom of page 21) states that: "Finally, applications may define custom in-band messages using mode 13. The size of the message in bytes is encoded with 5 bits, so that the decoder can

Hi, I've a couple of questions about the jitterbuffer. First of all, I'm a bit confused about the code to use. 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

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