Re: [codec] #16: Multicast?

Brian Rosen <br@brianrosen.net> Tue, 11 May 2010 17:23 UTC

Return-Path: <br@brianrosen.net>
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 C11373A6D33 for <codec@core3.amsl.com>; Tue, 11 May 2010 10:23:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.038
X-Spam-Level:
X-Spam-Status: No, score=-0.038 tagged_above=-999 required=5 tests=[AWL=-0.373, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334]
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 Que4O-MUw80c for <codec@core3.amsl.com>; Tue, 11 May 2010 10:23:38 -0700 (PDT)
Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [67.18.150.162]) by core3.amsl.com (Postfix) with ESMTP id 1414C3A6960 for <codec@ietf.org>; Tue, 11 May 2010 10:22:13 -0700 (PDT)
Received: from neustargw.va.neustar.com ([209.173.53.233] helo=[192.168.128.74]) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from <br@brianrosen.net>) id 1OBt9T-0007FN-V2; Tue, 11 May 2010 12:21:52 -0500
User-Agent: Microsoft-Entourage/12.24.0.100205
Date: Tue, 11 May 2010 13:21:56 -0400
From: Brian Rosen <br@brianrosen.net>
To: Ben Schwartz <bmschwar@fas.harvard.edu>, Christian Hoene <hoene@uni-tuebingen.de>
Message-ID: <C80F0A74.33BBA%br@brianrosen.net>
Thread-Topic: [codec] #16: Multicast?
Thread-Index: AcrxLnSSfKoFo8Pq2U2anBoBkEol1A==
In-Reply-To: <1273595415.1684.33.camel@dell-desktop>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - brianrosen.net
Cc: codec@ietf.org
Subject: Re: [codec] #16: Multicast?
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: Tue, 11 May 2010 17:23:41 -0000

I agree with this.  I was in a group that did some research on this
(unpublished, unfortunately) and we confirmed that there is a cliff, around
500 ms round trip, after which conversation is impaired.  It is remarkably
consistent, is more or less independent of culture (with one interesting
exception), and is really a cliff: under it and further improvement is hard
to notice, over it and conversation is impaired, and the difference between
say 750 and 1500ms isn't all that significant.

Engineers who believe delay is a "less is better" quantity need to be
educated that it is not.  It is a threshold.

The interesting exception has to do where you notice the impairment first.
It is when you argue.  Turn-taking is what is impaired, and arguing requires
rapid turn-taking.

So the exception is in cultures where arguing verbally is discouraged.
Politeness masks the delay, somewhat.

Brian




On 5/11/10 12:30 PM, "Ben Schwartz" <bmschwar@fas.harvard.edu> wrote:

> 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
> 
> http://downloads.hindawi.com/journals/asp/2008/185248.pdf
> 
> 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.
> 
> --Ben
> 
> _______________________________________________
> codec mailing list
> codec@ietf.org
> https://www.ietf.org/mailman/listinfo/codec