Re: [codec] Thresholds and delay.

Ben Schwartz <> Tue, 11 May 2010 18:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 110413A6A70 for <>; Tue, 11 May 2010 11:06:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.03
X-Spam-Status: No, score=-4.03 tagged_above=-999 required=5 tests=[AWL=-0.650, 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 3ZrfrCTBS5z8 for <>; Tue, 11 May 2010 11:06:26 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 65B923A69ED for <>; Tue, 11 May 2010 11:06:26 -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 0D8B26653F4; Tue, 11 May 2010 14:06:15 -0400 (EDT)
From: Ben Schwartz <>
To: Marshall Eubanks <>
In-Reply-To: <>
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> <1273595415.1684.33.camel@dell-desktop> <>
Content-Type: text/plain; charset="UTF-8"
Date: Tue, 11 May 2010 14:06:14 -0400
Message-ID: <1273601174.1684.79.camel@dell-desktop>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.3
Content-Transfer-Encoding: 7bit
Subject: Re: [codec] Thresholds and delay.
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 18:06:28 -0000

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


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.