[Speex-dev] Re: Problem with beta 3 jitter buffer

Jean-Marc Valin jean-marc.valin at usherbrooke.ca
Mon Dec 31 14:50:34 PST 2007

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

> But now I have another question. If jitter_buffer_get returns
> 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.


> Best regards,
> Daniel
> P.S. We can move this conversation to the mailing list if you like,
> since the second part could also be interesting for other users.
> 2007/12/28, Jean-Marc Valin <jean-marc.valin at usherbrooke.ca>:
>> Hi Daniel,
>> I'll have a look at this when I have a bit of time. Did you test beta1
>> and beta2? Did you see the same problem?
>> Cheers,
>>         Jean-Marc
>> Daniel Schmidt a écrit :
>>> Hi Jean-Marc,
>>> I gave the new jitter buffer of beta 3 a try and experienced a
>>> problem. Under certain extreme conditions the jitter buffer seems to
>>> get into an invalid state and speex_jitter_get doesn't return any more
>>> packets. Unfortunately I wasn't able to find the problem in jitter.c
>>> yet, so I created a log file with the function calls in the format you
>>> described on the mailing list a few weeks ago. The jitter buffer is
>>> initialized with step size 160 and no settings are changed. I hope you
>>> can reproduce the behaviour with this data. If there's anything else I
>>> can do, please let me know.
>>> Thank you very much for all the great work!
>>> Daniel

More information about the Speex-dev mailing list