Re: [codec] Thresholds and delay.

Ben Schwartz <bmschwar@fas.harvard.edu> Wed, 12 May 2010 12:28 UTC

Return-Path: <bmschwar@fas.harvard.edu>
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 77DD328C147 for <codec@core3.amsl.com>; Wed, 12 May 2010 05:28:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.192
X-Spam-Level:
X-Spam-Status: No, score=-4.192 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_40=-0.185, 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 uCy0iOkaN80M for <codec@core3.amsl.com>; Wed, 12 May 2010 05:28:07 -0700 (PDT)
Received: from us19.unix.fas.harvard.edu (us19.unix.fas.harvard.edu [140.247.35.199]) by core3.amsl.com (Postfix) with ESMTP id 7D1633A67A6 for <codec@ietf.org>; Wed, 12 May 2010 05:23:14 -0700 (PDT)
Received: from [192.168.1.139] (c-71-192-160-188.hsd1.nh.comcast.net [71.192.160.188]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: bmschwar) by us19.unix.fas.harvard.edu (Postfix) with ESMTPSA id 5DBAFB002D; Wed, 12 May 2010 08:23:03 -0400 (EDT)
From: Ben Schwartz <bmschwar@fas.harvard.edu>
To: jari.hagqvist@nokia.com
In-Reply-To: <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> <0E94BEEABCAE4C4EAC18B13A7A5C2456529E25A60C@NOK-EUMSG-01.mgdnok.nokia.com>
Content-Type: text/plain; charset="UTF-8"
Date: Wed, 12 May 2010 08:23:02 -0400
Message-ID: <1273666982.5250.18.camel@dell-desktop>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.3
Content-Transfer-Encoding: 7bit
Cc: codec@ietf.org, stephen.botzko@gmail.com
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 12:28:08 -0000

On Wed, 2010-05-12 at 10:01 +0200, jari.hagqvist@nokia.com wrote:
> 
> 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?

Only in the user's head.  The psychoacoustics of echo are very different
depending on the echo time.  This means that the perceived echo-canceler
fidelity depends on the acoustic round-trip delay.  It also means that
the AEC should be retuned depending on the round-trip delay.

--Ben