Re: [codec] #16: Delay factor: algorithmic delay vs. transmission latency.

This is a great discussion, but I don't see how it is relevant. If the
question is should the new CODEC support 5 ms frames, then the answer
is probably yes. If there a compelling reason (like achieving better
quality or having algorithm delay that makes this irrelevant) we might
agree to a bigger minimum frame size. If the question is if the CODEC
should support 20ms and bigger compound frames, then the answer is
absolutely yes. There are use cases for both. I guess, the only
question for me, is if in case of 5 ms frames we care about
compression. The packet header overhead is fairly big that you might
use PCMU in this case.

P.S. From what I know about soft phones the delay component dependent
on frame size is 1x. There are other delay components, but they are
not frame size dependent.
_____________________________
Roman Shpount - www.telurix.com

On Sun, May 16, 2010 at 5:33 AM, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
> On Sun, 16 May 2010, Christian Hoene wrote:
>
>> At the first glance, I did see evidence for the 3x factor for IP gateways.
>> The best in class at a 40.4 ms one-way delay for G.711 (20ms packets) and a
>> 54.3 ms delay for G.729 (20ms packets) referring to Tables 4.1 and 4.2. The
>> algorithmic delay of G.729 is 15ms (5ms lookahead).  Thus, the algorithmic
>> delay was 20ms for G.711 (plus an unknown delay of PLC) and 25ms for G.729.
>> Thus, a factor of 3 seems to be valid (5msx2,9=53,3-40,4)
>
> One-way delay of 40.4ms for G.711 sounds like 20ms for packet size and 20ms
> for jitter buffer. I wouldn't call that "algorithmic delay", that's packet
> and jitter buffer delay, "algorithmic delay" for G.711 should be "zero" or
> am I getting the concepts wrong (since it doesn't do any compression).
>
> --
> Mikael Abrahamsson    email: swmike@swm.pp.se
> _______________________________________________
> codec mailing list
> codec@ietf.org
> https://www.ietf.org/mailman/listinfo/codec
>