Re: [codec] #16: Multicast?

Jean-Marc Valin <jean-marc.valin@octasic.com> Tue, 11 May 2010 17:53 UTC

Return-Path: <jean-marc.valin@octasic.com>
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 902B728C192 for <codec@core3.amsl.com>; Tue, 11 May 2010 10:53:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.649
X-Spam-Level:
X-Spam-Status: No, score=-0.649 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_50=0.001]
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 16S9hUWjR6p2 for <codec@core3.amsl.com>; Tue, 11 May 2010 10:53:39 -0700 (PDT)
Received: from MAILEXCH.octasic.com (mail.octasic.com [70.54.254.106]) by core3.amsl.com (Postfix) with ESMTP id 087DD3A69E3 for <codec@ietf.org>; Tue, 11 May 2010 10:53:38 -0700 (PDT)
Received: from [142.138.24.19] ([142.138.24.19]) by MAILEXCH.octasic.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 11 May 2010 13:53:27 -0400
Message-ID: <4BE99997.2090307@octasic.com>
Date: Tue, 11 May 2010 13:53:27 -0400
From: Jean-Marc Valin <jean-marc.valin@octasic.com>
User-Agent: Thunderbird 2.0.0.24 (X11/20100317)
MIME-Version: 1.0
To: Brian Rosen <br@brianrosen.net>
References: <C80F0A74.33BBA%br@brianrosen.net>
In-Reply-To: <C80F0A74.33BBA%br@brianrosen.net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 11 May 2010 17:53:27.0459 (UTC) FILETIME=[DBF7CF30:01CAF132]
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:53:40 -0000

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

Considering that the network delay is not a constant, you no longer have an 
absolute cliff. So reducing the delay means you can increase the distance 
without falling off the cliff.

	Jean-Marc

> 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
> 
> 
> _______________________________________________
> codec mailing list
> codec@ietf.org
> https://www.ietf.org/mailman/listinfo/codec