Re: [codec] Thresholds and delay.

<jari.hagqvist@nokia.com> Wed, 12 May 2010 08:01 UTC

Return-Path: <jari.hagqvist@nokia.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 B8BC33A6836 for <codec@core3.amsl.com>; Wed, 12 May 2010 01:01:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.998
X-Spam-Level:
X-Spam-Status: No, score=-3.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, 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 TRJfNLjRPU16 for <codec@core3.amsl.com>; Wed, 12 May 2010 01:01:49 -0700 (PDT)
Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 323BF3A67F5 for <codec@ietf.org>; Wed, 12 May 2010 01:01:49 -0700 (PDT)
Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o4C81PYJ023297; Wed, 12 May 2010 03:01:37 -0500
Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 12 May 2010 11:01:34 +0300
Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by vaebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 12 May 2010 11:01:25 +0300
Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 12 May 2010 11:01:21 +0300
Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Wed, 12 May 2010 10:01:20 +0200
From: jari.hagqvist@nokia.com
To: stephen.botzko@gmail.com
Date: Wed, 12 May 2010 10:01:18 +0200
Thread-Topic: [codec] Thresholds and delay.
Thread-Index: AcrxNwEJ3XyZfic9SVOFRSImfpVKyAAbsIUg
Message-ID: <0E94BEEABCAE4C4EAC18B13A7A5C2456529E25A60C@NOK-EUMSG-01.mgdnok.nokia.com>
References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <002c01cae939$5c01f400$1405dc00$@de> <CB68DF4CFBEF4942881AD37AE1A7E8C74B903454B3@IRVEXCHCCR01.corp.ad.broadcom.com> <009901caede1$43f366d0$cbda3470$@de> <BCB3F026FAC4C145A4A3330806FEFDA93AB072BCC6@EMBX01-HQ.jnpr.net> <20100510232234.16632o6l2ecu3wyy@mail.skype.net> <006101caf117$aaf3b2c0$00db1840$@de> <1273595415.1684.33.camel@dell-desktop> <2B114368-93C0-410B-AB66-53CA33E921A8@americafree.tv> <1273601174.1684.79.camel@dell-desktop> <AANLkTil5vUH54FplHjocvqC1dK8vnQ1dRTmiOJJo1P25@mail.gmail.com>
In-Reply-To: <AANLkTil5vUH54FplHjocvqC1dK8vnQ1dRTmiOJJo1P25@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_0E94BEEABCAE4C4EAC18B13A7A5C2456529E25A60CNOKEUMSG01mgd_"
MIME-Version: 1.0
X-OriginalArrivalTime: 12 May 2010 08:01:21.0111 (UTC) FILETIME=[4F070E70:01CAF1A9]
X-Nokia-AV: Clean
Cc: codec@ietf.org
Subject: Re: [codec] Thresholds and delay.
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: Wed, 12 May 2010 08:01:50 -0000

Stephen&co,

Generally I believe that AECs mainly take care of the acoustic echo generated in the phone itself (operating on the microphone signal, acoustic delay up to a few ms). Do you mean that there is additional processing on the receiving side for the echo returning from the B user side?

Best regards,
Jari

From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of ext stephen botzko
Sent: 11 May, 2010 21:19
To: Ben Schwartz
Cc: codec@ietf.org
Subject: Re: [codec] Thresholds and delay.

>>>
In the presence of echo, round-trip delay must be kept below 30 ms to
ensure that the echo is perceived as sidetone, according to the Springer
handbook of speech processing:
>>>
Though true, I don't think this is a mainstream consideration.

VOIP phones that are capable of speakerphone operation all have acoustic echo cancelers, and those cancelers are already tuned to deal with internet delays with other voice codecs.  Certainly our phones and videoconferencing systems do not have problems with path delays of this order (hundreds of milliseconds).

>From my own experience (not testing) I agree with Brian's claim that 500 ms round trip is acceptable for most conversation.

It does depend on what you are doing, and there are certainly tasks where much lower delays are needed.

Regards,
Stephen Botzko


On Tue, May 11, 2010 at 2:06 PM, Ben Schwartz <bmschwar@fas.harvard.edu<mailto:bmschwar@fas.harvard.edu>> wrote:
On Tue, 2010-05-11 at 12:48 -0400, Marshall Eubanks wrote:
> As a point of order, I object to any graphs without an available paper
> behind them.

I have located the first paper mentioned by Christian Hoene at
http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=81952
but of course it's paywalled.

One test in that paper told trained subjects to "Take turns reading
random numbers aloud as fast as possible", on a pair of handsets with
narrowband uncompressed audio and no echo.  Subjects were able to detect
round-trip delays down to 90 ms.  Conversational efficiency was impaired
even with round-trip delay of 100 ms.

Let me emphasize again that these delays are round-trip, not one-way,
there is no echo, and the task, while designed to expose latency, is
probably less demanding than musical performance.

In the presence of echo, round-trip delay must be kept below 30 ms to
ensure that the echo is perceived as sidetone, according to the Springer
handbook of speech processing:

(http://books.google.com/books?id=Slg10ekZBkAC&lpg=PA83&ots=wc9yM9WrCs&dq=sidetone%20delay%2030%20ms&lr&pg=PA84#v=onepage&q&f=false)

Such low delays are clearly impossible on many paths, but for Boston to
New York City (or London to Paris), ping times can be less than 18 ms,
making echo->sidetone conversion just barely possible for a codec with
5ms frames.

I accept Brian Rosen's claim that a slow conversation doesn't normally
suffer greatly from round-trip latencies up to 500 ms, but under some
circumstances much lower latencies are valuable.  Let's make sure
they're achievable for those who can use them.

--Ben

_______________________________________________
codec mailing list
codec@ietf.org<mailto:codec@ietf.org>
https://www.ietf.org/mailman/listinfo/codec