[Speex-dev] How does the jitter buffer "catch up"?
Jean-Marc.Valin at USherbrooke.ca
Sun Sep 18 18:42:40 PDT 2005
> 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 Valin <Jean-Marc.Valin at USherbrooke.ca>
Université de Sherbrooke
More information about the Speex-dev