Re: [vmeet] Audio echo

Henning Schulzrinne <hgs@cs.columbia.edu> Fri, 24 April 2009 21:57 UTC

Return-Path: <hgs@cs.columbia.edu>
X-Original-To: vmeet@core3.amsl.com
Delivered-To: vmeet@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F5993A684C for <vmeet@core3.amsl.com>; Fri, 24 Apr 2009 14:57:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.313
X-Spam-Level:
X-Spam-Status: No, score=-6.313 tagged_above=-999 required=5 tests=[AWL=0.286, BAYES_00=-2.599, 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 wtogiUF9BRsd for <vmeet@core3.amsl.com>; Fri, 24 Apr 2009 14:57:20 -0700 (PDT)
Received: from jalapeno.cc.columbia.edu (jalapeno.cc.columbia.edu [128.59.29.5]) by core3.amsl.com (Postfix) with ESMTP id 4C6923A6C5C for <vMeet@ietf.org>; Fri, 24 Apr 2009 14:57:04 -0700 (PDT)
Received: from ice.cs.columbia.edu (ice.cs.columbia.edu [128.59.18.177]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.14.3/8.14.1) with ESMTP id n3OLw3M8012503 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 24 Apr 2009 17:58:03 -0400 (EDT)
Message-Id: <44C4C11A-1E22-4E63-B40F-4C074346119E@cs.columbia.edu>
From: Henning Schulzrinne <hgs@cs.columbia.edu>
To: Brian Rosen <br@brianrosen.net>
In-Reply-To: <048201c9c520$99158700$cb409500$@net>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Date: Fri, 24 Apr 2009 17:58:03 -0400
References: <49F1FD36.4010208@bbiw.net> <A14D0D78-F418-430D-831C-96F4E132B062@gmail.com> <048201c9c520$99158700$cb409500$@net>
X-Mailer: Apple Mail (2.930.3)
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.65 on 128.59.29.5
Cc: vMeet@ietf.org, 'Dave CROCKER' <dcrocker@bbiw.net>
Subject: Re: [vmeet] Audio echo
X-BeenThere: vmeet@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF remote participation meeting services discussion <vmeet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/vmeet>, <mailto:vmeet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/vmeet>
List-Post: <mailto:vmeet@ietf.org>
List-Help: <mailto:vmeet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/vmeet>, <mailto:vmeet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Apr 2009 21:57:21 -0000

[changing subject lines to reflect the topic]

To amplify: Line echo and acoustic echo cancellation are very  
different problems; see

http://www.polycom.com/global/documents/support/technical/products/voice/vortex_choose_acoustic_echo_canceller.pdf

for a summary. (Short version: The so-called tail time is much longer  
for the acoustic echo canceller.)

Digital hybrids, such as the JK Audio one, are not meant for such  
applications - they only cancel line echo, although the basic  
operational model is not bad - essentially, we are running a call-in  
show.

ClearOne is a well-known company in that space; however, most of these  
boxes seem designed for professional installation in conference rooms,  
not just plopping them down on a table next to the screen in rooms  
holding hundreds of people. (All the microphones and speakers have to  
be wired through them to work.) They are also not exactly cheap. Thus,  
the audio installation for each IETF would have to be done by somebody  
trained on that equipment, not the usual hotel audio crew that sticks  
black tape over XLR cables.

However, you only need these fancy boxes if you run full-duplex. If  
you mute the floor microphones when the remote caller speaks (and vice  
versa), i.e., in half-duplex mode, there can be no acoustic echo. This  
is, I think, what Doug is proposing. This is more human effort, but a  
whole lot simpler to install.

Henning

On Apr 24, 2009, at 5:06 PM, Brian Rosen wrote:

> I believe your comment on the audio is incorrect.
>
> Let's say that no one has any echo cancel, and someone in the room  
> speaks.
> As you point out, you don't hear echo in the room.  The remote  
> participants
> would get the direct audio a bit later, and what also happens is  
> that some
> of the outgoing audio from the room bounces off the hybrid in older  
> phones
> and is reflected back to the bridge.  The bridge has echo  
> cancellation for
> this and the echo won't come back to the room.
>
> When a remote participant speaks, the sound comes out the speakers,  
> gets
> picked up by the microphone a bit later, and is sent back to the
> participant, delayed.  Most conference bridges can't actually deal  
> with
> this: they aren't equipped to have local echo.  In this regard, it's  
> not any
> different from two conference phones in use with a phone connection  
> between
> them.  If you don't do anything locally, you WILL get echo.
>
> However, there are devices available that are designed to link the  
> room PA
> to the phone line used for the audio connection, and they have the  
> same kind
> of echo cancellation that  conference phone does.  So, I think it  
> will work
> out okay, although we have to make sure we do that.
>
> For example:
> http://www.jkaudio.com/broadcast-host_dtails.htm
> http://www.biamp.com/nexia_tc.php
>
> Brian
>