Re: [codec] Thresholds and delay.

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0E7CE3A6A79 for <>; Tue, 11 May 2010 11:46:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.813
X-Spam-Status: No, score=-3.813 tagged_above=-999 required=5 tests=[AWL=-0.433, 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 xd2ls85GBW4Z for <>; Tue, 11 May 2010 11:46:55 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 671D828C203 for <>; Tue, 11 May 2010 11:46:45 -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 775604D5F14; Tue, 11 May 2010 14:46:34 -0400 (EDT)
From: Ben Schwartz <>
To: stephen botzko <>
In-Reply-To: <>
References: <> <002c01cae939$5c01f400$1405dc00$@de> <> <009901caede1$43f366d0$cbda3470$@de> <> <> <006101caf117$aaf3b2c0$00db1840$@de> <1273595415.1684.33.camel@dell-desktop> <> <1273601174.1684.79.camel@dell-desktop> <>
Content-Type: text/plain; charset="UTF-8"
Date: Tue, 11 May 2010 14:46:34 -0400
Message-ID: <1273603594.1684.102.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:46:56 -0000

On Tue, 2010-05-11 at 14:19 -0400, stephen botzko wrote:
> >>>
> 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.

In my experience, the biggest problem is in complex conferences with
many users at different latencies, and endpoints consisting of
multiple-microphone multiple-speaker systems scattered across a room and
frequently repositioned.

Anyway, I don't think it's very contentious that

(a) on high latency links (e.g. long distances), AEC will always be
needed in speakerphones,

(b) the perceived audio quality in the presence of AEC is improved by
very low round-trip acoustic latency, and

(c) AEC may be retuned at very low round-trip acoustic latency for
further improvement in perceived audio quality.

Very high audio quality may not yet be a major concern in this market,
but I think this working group is going to change that.