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

Mikael Abrahamsson <swmike@swm.pp.se> Sun, 16 May 2010 09:33 UTC

Return-Path: <swmike@swm.pp.se>
X-Original-To: codec@core3.amsl.com
Delivered-To: codec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19E413A6986 for <codec@core3.amsl.com>; Sun, 16 May 2010 02:33:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.494
X-Spam-Level:
X-Spam-Status: No, score=-4.494 tagged_above=-999 required=5 tests=[AWL=-0.104, BAYES_20=-0.74, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id USbSll0nlOMw for <codec@core3.amsl.com>; Sun, 16 May 2010 02:33:38 -0700 (PDT)
Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) by core3.amsl.com (Postfix) with ESMTP id 6B0153A696A for <codec@ietf.org>; Sun, 16 May 2010 02:33:36 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 9BCE79C; Sun, 16 May 2010 11:33:22 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 9AEDA9A; Sun, 16 May 2010 11:33:22 +0200 (CEST)
Date: Sun, 16 May 2010 11:33:22 +0200
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: Christian Hoene <hoene@uni-tuebingen.de>
In-Reply-To: <000301caf4d6$13e824c0$3bb86e40$@de>
Message-ID: <alpine.DEB.1.10.1005161131370.28457@uplift.swm.pp.se>
References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <000001cae173$dba012f0$92e038d0$@de> <r2q6e9223711004211010gfdee1a70q972e8239fef10435@mail.gmail.com> <001101cae177$e8aa6780$b9ff3680$@de> <t2t6e9223711004211119i6b107798pa01fc4b1d33debf1@mail.gmail.com> <002d01cae188$a330b2c0$e9921840$@de> <CB68DF4CFBEF4942881AD37AE1A7E8C74AB3F4A017@IRVEXCHCCR01.corp.ad.broadcom.com> <4BD11C50.2020206@usherbrooke.ca> <CB68DF4CFBEF4942881AD37AE1A7E8C74AB3F4A270@IRVEXCHCCR01.corp.ad.broadcom.com> <12151537-165D-426A-B71F-8B3D76BE4854@cisco.com> <CB68DF4CFBEF4942881AD37AE1A7E8C74B901372FE@IRVEXCHCCR01.corp.ad.broadcom.com> <20100430230756.13687lc1s5o89gsc@mail.skype.net> <CB68DF4CFBEF4942881AD37AE1A7E8C74B90345522@IRVEXCHCCR01.corp.ad.broadcom.com> <07C815A7! -8F3C-4F85-A275-4352D00 80EEA@cisco.com> <CB68DF4CFBEF4942881AD37AE1A7E8C74B9043D30B@IRVEXCHCCR01.corp.ad.broadcom.com> <20100516012830.989257nt8p7l2p4e@mail.skype.net> <000301caf4d6$13e824c0$3bb86e40$@de>
User-Agent: Alpine 1.10 (DEB 962 2008-03-14)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
Cc: codec@ietf.org, frank.kettler@head-acoustics.de
Subject: Re: [codec] #16: Delay factor: algorithmic delay vs. transmission latency.
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Codec WG <codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/codec>, <mailto:codec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/codec>
List-Post: <mailto:codec@ietf.org>
List-Help: <mailto:codec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/codec>, <mailto:codec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 16 May 2010 09:33:39 -0000

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