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

[Jean-Marc Valin]

Should be fixed in svn/git now. Sorry for the high jitter :-)

	Jean-Marc

Daniel Schmidt a écrit :
> 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
> 
>