Re: [codec] Thresholds and delay.

stephen botzko <stephen.botzko@gmail.com> Wed, 12 May 2010 10:43 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 A952C3A68D8 for <codec@core3.amsl.com>; Wed, 12 May 2010 03:43:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.207
X-Spam-Level:
X-Spam-Status: No, score=-0.207 tagged_above=-999 required=5 tests=[AWL=-0.809, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6]
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 iL9ZgyWP2M6v for <codec@core3.amsl.com>; Wed, 12 May 2010 03:43:23 -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 C1DA33A6843 for <codec@ietf.org>; Wed, 12 May 2010 03:43:22 -0700 (PDT)
Received: by wwb28 with SMTP id 28so1210054wwb.31 for <codec@ietf.org>; Wed, 12 May 2010 03:43:09 -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=01jXcwiCJpBk4wd6iWOktwTT/r0pr+GnBrTDTLFLVNM=; b=SqxtOLhkni3+OkGfrLEdh92VlHVz7JjqfLm3FQ+JksREQDyIw9e63PQU5tRmXwDMT7 lie/JLEM6s9lYUlRwNGzT1wJtM6lQdwiatmXcGtlbt6eWvTuwGen+Qrw6JhI671n5s67 y+73MR/785fgCr8eeqdBXxZzNP7pA2IoKIL5I=
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=UpmNUmjdGrN4NIzbltrHyAjPMKM/DQcxEA6Y3sF8NT+xainDn1ABvuI7uhuDns9yRG O7u+N2bVbqomcq0LLI/iSgUuLKvsIm0nDzrAabYO7HUHF7mKbFJhKdd6ndTWZotIm3dA gfRks0eE6iCqObQHGVccP6MSoymQjyMVvxNlo=
MIME-Version: 1.0
Received: by 10.216.158.1 with SMTP id p1mr4317326wek.202.1273660988920; Wed, 12 May 2010 03:43:08 -0700 (PDT)
Received: by 10.216.23.5 with HTTP; Wed, 12 May 2010 03:43:08 -0700 (PDT)
In-Reply-To: <0E94BEEABCAE4C4EAC18B13A7A5C2456529E25A60C@NOK-EUMSG-01.mgdnok.nokia.com>
References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <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>
Date: Wed, 12 May 2010 06:43:08 -0400
Message-ID: <AANLkTinxZ_2IynMcbhH3Mn4gwnpYIFmUr2ucEzfZoHaS@mail.gmail.com>
From: stephen botzko <stephen.botzko@gmail.com>
To: jari.hagqvist@nokia.com
Content-Type: multipart/alternative; boundary="0016e649c490cf19360486634e2a"
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 10:43:25 -0000

Acoustic echo cancelers remove the signal from the local speaker(s) that is
feeding back into the local microphone(s).  So if *my* AEC is turned off,
then *you* will hear the echo (and I will not).

The echo that *you* hear is delayed by the round trip transport time, the
processing delays in the sender and receiver, and the acoustic path delay
between the speaker and the microphone.  However, the echo that the
*AEC*detects is only delayed the acoustic path delay and whatever
processing
delay (buffering) the receiver has on its audio capture and render
circuitry.

So you are correct if you are thinking that the network transport time and
codec delay do not impact the requirements for the AEC.

There can also be path delay between the receiver output and the actual
speaker.  For instance in a video conferencing application, the video
processing in the TV itself can add delay, and the TV will delay the audio
to maintain sync.  So if your phone system can be connected to external
sound systems, then that can effect the delays the AEC has to accommodate.

Also, in larger rooms the acoustic path delay can be substantial since sound
takes about 100 ms to travel 100 feet  (341 meters per second).

Regards
Stephen Botzko

On Wed, May 12, 2010 at 4:01 AM, <jari.hagqvist@nokia.com> wrote:

>  Stephen&co,
>
>
>
> 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?
>
>
>
> Best regards,
>
> Jari
>
>
>
> *From:* codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] *On Behalf
> Of *ext stephen botzko
> *Sent:* 11 May, 2010 21:19
> *To:* Ben Schwartz
> *Cc:* codec@ietf.org
>
> *Subject:* Re: [codec] Thresholds and delay.
>
>
>
> >>>
>
> 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.  Certainly our phones and videoconferencing
> systems do not have problems with path delays of this order (hundreds of
> milliseconds).
>
> From my own experience (not testing) I agree with Brian's claim that 500 ms
> round trip is acceptable for most conversation.
>
> It does depend on what you are doing, and there are certainly tasks where
> much lower delays are needed.
>
> Regards,
> Stephen Botzko
>
>
>  On Tue, May 11, 2010 at 2:06 PM, Ben Schwartz <bmschwar@fas.harvard.edu>
> wrote:
>
> 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
> http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=81952
> 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:
>
> (
> http://books.google.com/books?id=Slg10ekZBkAC&lpg=PA83&ots=wc9yM9WrCs&dq=sidetone%20delay%2030%20ms&lr&pg=PA84#v=onepage&q&f=false
> )
>
> 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.
>
> --Ben
>
> _______________________________________________
> codec mailing list
> codec@ietf.org
> https://www.ietf.org/mailman/listinfo/codec
>
>
>