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