Re: [codec] #14: VAD and CNG?

"Christian Hoene" <hoene@uni-tuebingen.de> Mon, 24 May 2010 17:43 UTC

Return-Path: <hoene@uni-tuebingen.de>
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 806A03A6C44 for <codec@core3.amsl.com>; Mon, 24 May 2010 10:43:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.332
X-Spam-Level:
X-Spam-Status: No, score=-1.332 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_50=0.001, HELO_EQ_DE=0.35, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_MED=-4, RCVD_IN_SORBS_WEB=0.619]
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 TKJIOMdD7j97 for <codec@core3.amsl.com>; Mon, 24 May 2010 10:43:28 -0700 (PDT)
Received: from mx05.uni-tuebingen.de (mx05.uni-tuebingen.de [134.2.3.4]) by core3.amsl.com (Postfix) with ESMTP id 420F83A6D09 for <codec@ietf.org>; Mon, 24 May 2010 10:43:28 -0700 (PDT)
Received: from hoeneT60 ([82.113.121.147]) (authenticated bits=0) by mx05.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id o4OHh83E001665 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 24 May 2010 19:43:16 +0200
From: Christian Hoene <hoene@uni-tuebingen.de>
To: bens@alum.mit.edu
References: <C82009F2.35809%br@brianrosen.net> <C81FF1F7.16BE0%mknappe@juniper.net> <000f01cafb61$efe237e0$cfa6a7a0$@de> <4BFAB63E.3090408@fas.harvard.edu>
In-Reply-To: <4BFAB63E.3090408@fas.harvard.edu>
Date: Mon, 24 May 2010 19:43:04 +0200
Message-ID: <002701cafb68$960cc3f0$c2264bd0$@de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Acr7ZfQndiA3cTteQqqUaOWA1c3n/QAAbp0g
Content-Language: de
X-AntiVirus-Spam-Check: clean (checked by Avira MailGate: version: 3.0.0-4; spam filter version: 3.0.0/2.0; host: mx05)
X-AntiVirus: checked by Avira MailGate (version: 3.0.0-4; AVE: 8.2.1.242; VDF: 7.10.7.163; host: mx05); id=17691-2IRMfd
Cc: codec@ietf.org
Subject: Re: [codec] #14: VAD and CNG?
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: Mon, 24 May 2010 17:43:29 -0000

Hi Benjamin,


>In general, parameters for bitrate, jitter buffer, sample rate, filtering, and AEC are not exposed to
>the user.  They are typically managed according to some customized algorithm designed for the
>hardware, network, and application.  DTX is just one more of these settings, and would be no more
>likely to be exposed to the user.  We don't need to worry about the user interface, because in most
>cases there won't be one.

Actually, I meant two kind of users: Those of the phone and those of the codec.
>
>I think it's a good idea for the reference implementation to provide some intelligent heuristics for
>use of DTX, but these heuristics should not be a requirement of any RFC.

Yes, you are true. But we must be precise. The requirement for some heuristics on how to set those parameters MUST be part of the
requirements document. However, the heuristics NEED NOT to be implemented in every phone but the implementer CAN choose any superior
algorithm to optimize particular application needs. Thus, a heuristic on how to select DTX should only ensure some minimal system
quality.

Christian

>
>--Ben