Re: [codec] #16: Multicast?

Marshall Eubanks <tme@americafree.tv> Tue, 11 May 2010 16:48 UTC

Return-Path: <tme@americafree.tv>
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 4B9AF3A6933 for <codec@core3.amsl.com>; Tue, 11 May 2010 09:48:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.565
X-Spam-Level:
X-Spam-Status: No, score=-100.565 tagged_above=-999 required=5 tests=[AWL=-0.566, BAYES_50=0.001, USER_IN_WHITELIST=-100]
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 A1RhJoAkN4Aw for <codec@core3.amsl.com>; Tue, 11 May 2010 09:48:44 -0700 (PDT)
Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id 0BD083A67CC for <codec@ietf.org>; Tue, 11 May 2010 09:48:43 -0700 (PDT)
Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id CFD6870DAF07; Tue, 11 May 2010 12:48:31 -0400 (EDT)
Message-Id: <2B114368-93C0-410B-AB66-53CA33E921A8@americafree.tv>
From: Marshall Eubanks <tme@americafree.tv>
To: Ben Schwartz <bmschwar@fas.harvard.edu>
In-Reply-To: <1273595415.1684.33.camel@dell-desktop>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Tue, 11 May 2010 12:48:29 -0400
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> <CB68DF4CFBEF4942881AD37AE1A7E8C74AB3F4A287@IRVEXCHCCR01.corp.ad.broadcom.com> <002c01cae939$5c01f400$1405dc00$@de> <CB68DF4CFBEF4942881AD37AE1A7E8C74B903454B3@IRVEXCHCCR01.corp.ad.broadcom.com> , <009901caede1$43f366d0$cbda3470$@de> <BCB3F026FAC4C145A4A3330806FEFDA93AB072BCC6@EMBX01-HQ.jnpr.net> <CB68DF4CFBEF4942881AD37AE1A7E8C74B90345C0D@IRV ! E XCHCC... <1273441939. 4be72e937fdf5@webmail.fas.harvard.edu> <20100510232234.16632o6l2ecu3wyy@mail.skype.net> <006101caf117$aaf3b2c0$00db1840$@de> <1273595415.1684.33.camel@dell-desktop>
X-Mailer: Apple Mail (2.936)
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 16:48:45 -0000

On May 11, 2010, at 12:30 PM, Ben Schwartz 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
>

As a point of order, I object to any graphs without an available paper  
behind them.

> (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.
>

This depends a lot on what sort of discussion is at issue (and, also  
on the culture of the participants).

For example, in my experience telepresence sessions tend to be  
structured meetings and can typically tolerate even half second delays  
without too much disruption, while for a one-on-one conversation on  
the same equipment the same delay can be pretty objectionable.

Having said that, I myself also find the previously attached graphs a  
little odd, and want to see a written description of just what sort of  
experiments they describe.

> 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.

Again, without the papers behind them, we are wasting our time having  
such discussions.

Regards
Marshall

P.S. This thread has wandered far from multicast...


>
> (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
>