[Speex-dev] How does the jitter buffer "catch up"?

[Jean-Marc Valin]

> Err, unless I'm totally wrong, there are a few race conditions.
> 
> Assume the buffer is full of packets newer than the current pointer, and 
> one that is at the current pointer.
> 
> get and put start at the same time.
> 
> get will find the correct buffer index. Now, just after it finds it's 
> index, assume we switch to the put thread.
> 
> Put needs to put a new packet in, so discards the oldest, which is the 
> current packet, and replaces it with the new one (let's call it newest).
[...]

True. It was originally race-safe when I was discarding the incoming
packet in case of buffer full. I changed that behaviour exactly because
of burst issues and the like. Other than that, I don't think there
should be any other possible race (assuming CPU cache coherence).

> > Why would you do that. The idea of interpolating a frame is exactly to
> > get better quality than just putting zeros.
> 
> Actually, I oversimplified a bit. I check if valid_bits has been zero for 
> the last 4 frames or more, because once you interpolate more than 100ms 
> from the last known state, you end up with some weird 
> blipp-blopp-blooiiing sound. Actually it reminds me of the ambient sound 
> of weird aliens in bad 50s scifi movies. At that point, silence is much 
> better :)

Then it would be a problem with the packet loss concealment. It's
actually decreasing the level of the interpolated audio with time. Maybe
it's not decreasing quickly enough?

	Jean-Marc

-- 
Jean-Marc Valin <Jean-Marc.Valin at USherbrooke.ca>
Université de Sherbrooke