Re: [codec] Thresholds and delay.

stephen botzko <stephen.botzko@gmail.com> Wed, 12 May 2010 15:01 UTC

Return-Path: <stephen.botzko@gmail.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 19E6A28C28B for <codec@core3.amsl.com>; Wed, 12 May 2010 08:01:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.465
X-Spam-Level:
X-Spam-Status: No, score=-0.465 tagged_above=-999 required=5 tests=[AWL=-0.467, BAYES_50=0.001, HTML_MESSAGE=0.001]
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 d0-675VkN9pN for <codec@core3.amsl.com>; Wed, 12 May 2010 08:01:33 -0700 (PDT)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 4E4DA28C2E2 for <codec@ietf.org>; Wed, 12 May 2010 07:48:08 -0700 (PDT)
Received: by wwb28 with SMTP id 28so49655wwb.31 for <codec@ietf.org>; Wed, 12 May 2010 07:47:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=0nwi7076IsGuXN5yNopG7wmesX5OIQV3G6DD8atL9Nw=; b=IutZHQQ1kwxEiKXZ8HidMGyj6BPum+GlHi17prNxmk+yD9Aj+dngeZIy9xsEaLtRRH HK5WV6ZCf1y3V6aTbMkSN7dVUHutgz6+l+GHPVT5FS+MLv7IVgw45xU4J5C6xUzVQltp iHDbV+q6B5lcZ8nn2aOnSg6OZjHo4g+tIdMC8=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=mKiEzjQm7fAziYmzt8Hu/A5re9F4GtwNhMdQPrlTE6HZEHnELtj5B1KIcjmgR2MT3n GbcFlCdxd4LsvpEdUxoKWlgOQ3Ag5gPt0gTZbgdrJKc+8bhQeen+U9GXZjmDoThhkVgD Xsknh1Ig8iP8F/WUjmwtyGEjtqQuWZPYcB7pE=
MIME-Version: 1.0
Received: by 10.216.91.80 with SMTP id g58mr1018977wef.181.1273675674860; Wed, 12 May 2010 07:47:54 -0700 (PDT)
Received: by 10.216.23.5 with HTTP; Wed, 12 May 2010 07:47:54 -0700 (PDT)
In-Reply-To: <1273666982.5250.18.camel@dell-desktop>
References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <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> <1273666982.5250.18.camel@dell-desktop>
Date: Wed, 12 May 2010 10:47:54 -0400
Message-ID: <AANLkTilMELtiIKUAhSBEsCSufFOVGRLgpIhvXQDeKYiV@mail.gmail.com>
From: stephen botzko <stephen.botzko@gmail.com>
To: Ben Schwartz <bmschwar@fas.harvard.edu>
Content-Type: multipart/alternative; boundary="0016e6d9762628bf93048666ba66"
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 15:01:35 -0000

>>>
   It also means that the AEC should be retuned depending on the round-trip
delay.
>>>
Jari is (I think) pointing out that this last statement is not true.

I agree with Jari's assessment, though I am not sure exactly what you mean
by "retuning".  The far-end user will perceive the fed-back echo in various
ways, and that does depend on the round-trip time.  However, the job of the
AEC is to remove the echo, so there is no fed-back echo to hear.  And the
algorithms which remove echo do *not* depend on the round-trip delay to the
far end.  At least not the good ones.

Perhaps more substantively, I do not think this AEC discussion actually
matters in this WG context.  We are not working on an AEC, we are working on
an Internet Codec.  Even if (for argumentation purposes) you accept the idea
that somehow the AEC needs to be tuned to the round-trip delay, the
round-trip delay varies enormously depending on the connection, and this
round-trip time in general is not even discoverable (esp. if gateways or
SBCs are used).  Nothing we are doing in this group will change any of the
above.

As far as sidetone goes, I do not understand why that keeps coming up
either.

For the speakerphone use case eliminating AECs from both ends requires two
conditions:
(a) the round trip delay has to be very low (30 ms or less, from all delay
sources)
(b) there has to be sufficient attenuation on the loop.

The first condition has been brought up repeatedly.  For general internet
WAN connections it is clearly not met, and it is in fact difficult to meet
even on more local connections.

The second condition has not been discussed much.  But if you do have low
delay but do not have enough attenuation, what you get is feedback, and not
sidetone.  Since users have control over the speaker volume, the second
condition (in general) also can not be guaranteed.

All speakerphones that I know of are either half-duplex or use AECs.  This
is true even for PSTN phones used in local-loop circuit-switched calls,
which is the lowest delay telephony connection that there is.  So for
telephony at least, it is clear that AECs are needed.

So I do not think continued debate on the value of sidetone is productive.
I agree with Michael's comment "achieving low enough latencies for sidetone
perception should not be a goal of the wg"

Stephen Botzko

On Wed, May 12, 2010 at 8:23 AM, Ben Schwartz <bmschwar@fas.harvard.edu>wrote:

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