Re: [codec] #16: Multicast?

Ben Schwartz <> Tue, 11 May 2010 16:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1F8F73A6C42 for <>; Tue, 11 May 2010 09:30:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.68
X-Spam-Status: No, score=-4.68 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4, RCVD_IN_SORBS_WEB=0.619]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gP1qcns+CuK7 for <>; Tue, 11 May 2010 09:30:34 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5FA463A6BE6 for <>; Tue, 11 May 2010 09:30:30 -0700 (PDT)
Received: from [] ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: bmschwar) by (Postfix) with ESMTPSA id 8DFA3110686; Tue, 11 May 2010 12:30:19 -0400 (EDT)
From: Ben Schwartz <>
To: Christian Hoene <>
In-Reply-To: <006101caf117$aaf3b2c0$00db1840$@de>
References: <> <> <> <> <> <000001cae173$dba012f0$92e038d0$@de> <> <001101cae177$e8aa6780$b9ff3680$@de> <> <002d01cae188$a330b2c0$e9921840$@de> <> <> <> <002c01cae939$5c01f400$1405dc00$@de> <> , <009901caede1$43f366d0$cbda3470$@de> <> <CB68DF4CFBEF4942881AD37AE1A7E8C74B90345C0D@IRV! E XCHCC... <1273441939.> <> <006101caf117$aaf3b2c0$00db1840$@de>
Content-Type: text/plain; charset="UTF-8"
Date: Tue, 11 May 2010 12:30:15 -0400
Message-ID: <1273595415.1684.33.camel@dell-desktop>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.3
Content-Transfer-Encoding: 7bit
Subject: Re: [codec] #16: Multicast?
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Codec WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 11 May 2010 16:30:36 -0000

On Tue, 2010-05-11 at 16:38 +0200, Christian Hoene wrote:
>  Until 400ms quality is still acceptable (about toll quality). The
> ITU-T G.107 quality model reflects this opinion.
> However, in the recent years, new results have shown that the impact
> of delay on conversation quality is NOT as strong as assumed.

I have been unable to locate the paper that is the source of these
claims.  However, I will note that

(1) The results conflict with common sense.  A round-trip delay of 800
ms makes normal conversation extremely irritating in practice.  I'm not
surprised these results don't show up in laboratory tests, because fast
conversations with interjections and rapid responses typically require a
social context not available in a lab test.

It's possible that the ITU regards "extremely irritating" as
"acceptable", since effective conversation is still possible.  In that
case, I would say that the working group intends to enable applications
with much better than "acceptable" quality.

(2) Tests may have been done in G.711 narrowband, which introduces its
own intelligibility problems and reduces quality expectation.  Higher
fidelity makes latency more apparent.  Similarly, the equipment used may
have introduced quality impairments that make the delay merely one
problem among many.

(3) I presume the tests were done with careful equipment setup to avoid
echo.  The perceived quality impact of echo at 200 ms one-way delay is
enormous, as shown in

Using an echo-canceller impairs quality significantly.  Imperfect echo
cancellation leaves some residual artifact, which is also irritating at
long delays.

The tests (even in the paper above) were performed using a telephone
handset and earpiece.  High-quality telephony with a freestanding
speaker instead of an earpiece demands especially low delay due to the
difficulties with echo cancellation.