[Speex-dev] Jitter Buffer issues
Jean-Marc Valin
jean-marc.valin at usherbrooke.ca
Tue Sep 16 04:35:42 PDT 2008
> I think the problem
> is in compute_opt_delay() in the way it finds the latest packet.
> Currently it finds the most resent packet in the timing buffer not the
> oldest packet. The oldest packet is found once the timing buffer is
> reset and only one frame is in the tb[0].
>
>
> int latest = 32767;
> /* Pick latest amoung all sub-windows */
> for (j=0;j<MAX_BUFFERS;j++)
> {
> if (pos[j] < tb[j].filled && tb[j].timing[pos[j]] < latest)
> {
> next = j;
> latest = tb[j].timing[pos[j]];
> }
> }
>
> I think it should be
>
> int latest = 0;
> /* Pick latest among all sub-windows */
> for (j=0;j<MAX_BUFFERS;j++)
> {
> if (pos[j] < tb[j].filled && tb[j].timing[pos[j]] > latest)
> {
> next = j;
> latest = tb[j].timing[pos[j]];
> }
> }
Whatever this does, it's probably a side effect of being buggy. If you
look at what goes into timing, it's (timestemp_of_the_packet -
timestamp_we_re_playing) if a packet is late, it means that its
timestamp is smaller the the timestamp we're playing, which means that
"timing" is on the negative side. Thus, we're looking for the smallest
timing we can find.
As for the margin, your mileage may vary. A margin of zero gives better
latency, but a bit more late packets.
Jean-Marc
More information about the Speex-dev
mailing list