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 > > >
- [codec] #16: Multicast? codec issue tracker
- Re: [codec] #16: Multicast? Colin Perkins
- Re: [codec] #16: Multicast? Christian Hoene
- Re: [codec] #16: Multicast? Marshall Eubanks
- Re: [codec] #16: Multicast? stephen botzko
- Re: [codec] #16: Multicast? Colin Perkins
- Re: [codec] #16: Multicast? Colin Perkins
- Re: [codec] #16: Multicast? stephen botzko
- Re: [codec] #16: Multicast? Christian Hoene
- Re: [codec] #16: Multicast? stephen botzko
- Re: [codec] #16: Multicast? Marshall Eubanks
- Re: [codec] #16: Multicast? Christian Hoene
- Re: [codec] #16: Multicast? stephen botzko
- Re: [codec] #16: Multicast? Christian Hoene
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Jean-Marc Valin
- Re: [codec] #16: Multicast? Koen Vos
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Mikael Abrahamsson
- Re: [codec] #16: Multicast? Jean-Marc Valin
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Koen Vos
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? stephen botzko
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Koen Vos
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Mikael Abrahamsson
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Mikael Abrahamsson
- Re: [codec] #16: Multicast? (Bluetooth) Koen Vos
- Re: [codec] #16: Multicast? Koen Vos
- Re: [codec] #16: Multicast? stephen botzko
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Koen Vos
- Re: [codec] #16: Multicast? (Bluetooth) Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? (Bluetooth) stephen botzko
- Re: [codec] #16: Multicast? Christian Hoene
- Re: [codec] #16: Multicast? Christian Hoene
- Re: [codec] #16: Multicast? Christian Hoene
- Re: [codec] #16: Multicast? (USB) Roni Even
- Re: [codec] #16: Multicast? codec issue tracker
- Re: [codec] #16: Multicast? stephen botzko
- Re: [codec] #16: Multicast? Cullen Jennings
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Mikael Abrahamsson
- Re: [codec] #16: Multicast? Koen Vos
- Re: [codec] #16: Multicast? (Bluetooth) Koen Vos
- Re: [codec] #16: Multicast? stephen botzko
- Re: [codec] #16: Multicast? Christian Hoene
- Re: [codec] #19: How large is the frame size depe… Christian Hoene
- Re: [codec] #19: How large is the frame size depe… stephen botzko
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #19: How large is the frame size depe… Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? (Bluetooth) Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? stephen botzko
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? stephen botzko
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Koen Vos
- Re: [codec] #16: Multicast? Christian Hoene
- Re: [codec] #16: Multicast? Gregory Maxwell
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Koen Vos
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Koen Vos
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Koen Vos
- Re: [codec] #16: Multicast? Koen Vos
- Re: [codec] #16: Multicast? Benjamin M. Schwartz
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Kevin P. Fleming
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Jean-Marc Valin
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Jean-Marc Valin
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Christian Hoene
- Re: [codec] #16: Multicast? Koen Vos
- Re: [codec] #16: Multicast? Christian Hoene
- Re: [codec] #16: Multicast? Ben Schwartz
- Re: [codec] #16: Multicast? Marshall Eubanks
- Re: [codec] #16: Multicast? Brian Rosen
- Re: [codec] #16: Multicast? Christian Hoene
- Re: [codec] #16: Multicast? Jean-Marc Valin
- Re: [codec] Thresholds and delay. Ben Schwartz
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] Thresholds and delay. stephen botzko
- Re: [codec] #16: Multicast? Christian Hoene
- Re: [codec] Thresholds and delay. Ben Schwartz
- Re: [codec] #20: Computational complexity? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] Thresholds and delay. jari.hagqvist
- Re: [codec] Thresholds and delay. stephen botzko
- Re: [codec] Thresholds and delay. Ben Schwartz
- Re: [codec] Thresholds and delay. Marshall Eubanks
- Re: [codec] Thresholds and delay. stephen botzko
- Re: [codec] #16: Multicast? Cullen Jennings
- Re: [codec] Thresholds and delay. Michael Knappe
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Koen Vos
- Re: [codec] #16: Delay factor: algorithmic delay … Christian Hoene
- Re: [codec] #16: Delay factor: algorithmic delay … Mikael Abrahamsson
- Re: [codec] #16: Delay factor: algorithmic delay … Roman Shpount
- Re: [codec] #16: Delay factor: algorithmic delay … stephen botzko
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Cullen Jennings
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Koen Vos
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Koen Vos
- Re: [codec] #16: Multicast? Christian Hoene
- Re: [codec] #16: Multicast? Jean-Marc Valin
- Re: [codec] #16: Multicast? Herve Taddei
- Re: [codec] #16: Multicast? Christian Hoene
- Re: [codec] #16: Multicast? Jean-Marc Valin
- Re: [codec] #16: Multicast? Sandy (Alexander) MacInnis
- Re: [codec] #16: Multicast? Christian Hoene
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Roman Shpount
- Re: [codec] #16: Multicast? Herve Taddei
- Re: [codec] #16: Multicast? Cullen Jennings
- [codec] Suggested summary... Christian Hoene
- Re: [codec] Suggested summary... stephen botzko
- Re: [codec] Suggested summary... Herve Taddei
- Re: [codec] Suggested summary... Christian Hoene
- Re: [codec] Suggested summary... Michael Knappe
- Re: [codec] Suggested summary... Herve Taddei
- Re: [codec] Suggested summary... stephen botzko
- Re: [codec] Suggested summary... Christian Hoene
- Re: [codec] Suggested summary... Christian Hoene
- Re: [codec] Suggested summary... stephen botzko
- Re: [codec] Suggested summary... Raymond (Juin-Hwey) Chen
- Re: [codec] Suggested summary... Christian Hoene
- Re: [codec] Suggested summary... Herve Taddei
- Re: [codec] Suggested summary... Raymond (Juin-Hwey) Chen