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

"Christian Hoene" <hoene@uni-tuebingen.de> Sun, 16 May 2010 08:59 UTC

Return-Path: <hoene@uni-tuebingen.de>
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 468763A6965 for <codec@core3.amsl.com>; Sun, 16 May 2010 01:59:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.493
X-Spam-Level:
X-Spam-Status: No, score=-3.493 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_50=0.001, HELO_EQ_DE=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 aFUuSgnJmMEN for <codec@core3.amsl.com>; Sun, 16 May 2010 01:59:45 -0700 (PDT)
Received: from mx05.uni-tuebingen.de (mx05.uni-tuebingen.de [134.2.3.4]) by core3.amsl.com (Postfix) with ESMTP id 704773A695F for <codec@ietf.org>; Sun, 16 May 2010 01:59:45 -0700 (PDT)
Received: from hoeneT60 ([178.2.216.228]) (authenticated bits=0) by mx05.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id o4G8xGNv020803 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 16 May 2010 10:59:22 +0200
From: Christian Hoene <hoene@uni-tuebingen.de>
To: 'Koen Vos' <koen.vos@skype.net>
References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <3E1D8AD1-B28F-41C5-81C6-478A15432224@csperkins.org> <D6C2F445-BE4A-4571-A56D-8712C16887F1@americafree.tv> <C0347188-A2A1-4681-9F1E-0D2ECC4BDB3B@csperkins.org> <u2x6e9223711004210733g823b4777y404b02330c49dec1@mail.gmail.com> <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>
In-Reply-To: <20100516012830.989257nt8p7l2p4e@mail.skype.net>
Date: Sun, 16 May 2010 10:59:15 +0200
Message-ID: <000301caf4d6$13e824c0$3bb86e40$@de>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Acr00c7lCTYNe9/TQciy5po8uV4kZgAAcgaw
Content-Language: de
X-AntiVirus-Spam-Check: clean (checked by Avira MailGate: version: 3.0.0-4; spam filter version: 3.0.0/2.0; host: mx05)
X-AntiVirus: checked by Avira MailGate (version: 3.0.0-4; AVE: 8.2.1.242; VDF: 7.10.7.111; host: mx05); id=4664-p2aMaf
Cc: frank.kettler@head-acoustics.de, codec@ietf.org
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 08:59:47 -0000

Hi, 

some recent studies on the speech quality of gateways and IP phones are present in 
http://www.head-acoustics.de/telecomfiles/5th_ETSI_SQTE_Anonymous_Test_Report.doc
Please have a look at the document first...

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)

In case of IP phones it is not that clear. Actually, I did not fully understand the document. That is 2N and 8N application force?

I bet the experts from HEAD acoustic could bring some light into this discussion and explain, whether they have seen something like
a 3x factor between the algorithmic delay and the final latency.

For, we could officially send a liaison statement to ETSI asking for more data.

With best regards,

 Christian




---------------------------------------------------------------
Dr.-Ing. Christian Hoene
Interactive Communication Systems (ICS), University of Tübingen 
Sand 13, 72076 Tübingen, Germany, Phone +49 7071 2970532 
http://www.net.uni-tuebingen.de/

>-----Original Message-----
>From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of Koen Vos
>Sent: Sunday, May 16, 2010 10:29 AM
>To: Raymond (Juin-Hwey) Chen
>Cc: codec@ietf.org
>Subject: Re: [codec] #16: Multicast?
>
>Quoting "Raymond (Juin-Hwey) Chen":
>
>> I didn't come up with this 3*(codec frame size) delay number for IP
>> phones myself.  A very senior technical lead in Broadcom's IP phone
>> chips group told me that
>
>Still:
>- You've presented no satisfactory explanation for your theory
>- Nor any verifiable empirical evidence
>- It comes from an anonymous source
>- It has changed over time (going from 5x to 3x)
>- It goes against accepted wisdom
>
>So I'd say the burden of proof is on you..
>
>koen.
>_______________________________________________
>codec mailing list
>codec@ietf.org
>https://www.ietf.org/mailman/listinfo/codec