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

[Daniel Schmidt]

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

In my case the sender slowed down (probably due to high cpu
utilization) without showing the resulting gaps in the packet numbers.
So the jitter buffer had to call shift_timings quite often in a short
period of time and this caused the overflows. You can reproduce this
with the log file I sent you.
Also if you use audio samples as timing units and have a codec like
vorbis with a sample rate 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.
> 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 by
speexclient always interpolates/inserts one speex frame if
jitter_buffer_get doesn't return JITTER_BUFFER_OK without taking
packet->span into account. Therefore my question was if this is
correct or the number of frames to insert (before calling
jitter_buffer_get again) must be determined by packet->span or if the
jitter buffer can be used in both ways.

Best regards,
Daniel