Re: [codec] #16: Multicast?

"Christian Hoene" <hoene@uni-tuebingen.de> Sat, 01 May 2010 14:20 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 A63343A6BAE for <codec@core3.amsl.com>; Sat, 1 May 2010 07:20:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.071
X-Spam-Level:
X-Spam-Status: No, score=-4.071 tagged_above=-999 required=5 tests=[AWL=-0.422, BAYES_50=0.001, HELO_EQ_DE=0.35, 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 xJCKJPa828f7 for <codec@core3.amsl.com>; Sat, 1 May 2010 07:20:10 -0700 (PDT)
Received: from mx05.uni-tuebingen.de (mx05.uni-tuebingen.de [134.2.3.4]) by core3.amsl.com (Postfix) with ESMTP id F361B3A6BA8 for <codec@ietf.org>; Sat, 1 May 2010 07:20:06 -0700 (PDT)
Received: from hoeneT60 ([178.2.215.148]) (authenticated bits=0) by mx05.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id o41EJhIf018398 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 1 May 2010 16:19:48 +0200
From: Christian Hoene <hoene@uni-tuebingen.de>
To: "'Raymond (Juin-Hwey) Chen'" <rchen@broadcom.com>
References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <3E1D8AD1-B28F-41C5-81C6-478A15432224@csperkins.org> <D6C2F445-BE4A-4571-A56D-8712C16887F1@americafree.tv> <C0347188-A2A1-4681-9F1E-0D2ECC4BDB3B@csperkins.org> <u2x6e9223711004210733g823b4777y404b02330c49dec1@mail.gmail.com> <000001cae173$dba012f0$92e038d0$@de> <r2q6e9223711004211010gfdee1a70q972e8239fef10435@mail.gmail.com> <001101cae177$e8aa6780$b9ff3680$@de> <t2t6e9223711004211119i6b107798pa01fc4b1d33debf1@mail.gmail.com> <002d01cae188$a330b2c0$e9921840$@de> <CB68DF4CFBEF4942881AD37AE1A7E8C74AB3F4A017@IRVEXCHCCR01.corp.ad.broadcom.com> <4BD11C50.2020206@usherbrooke.ca> <CB68DF4CFBEF4942881AD37AE1A7E8C74AB3F4A287@IRVEXCHCCR01.corp.ad.broadcom.com>
In-Reply-To: <CB68DF4CFBEF4942881AD37AE1A7E8C74AB3F4A287@IRVEXCHCCR01.corp.ad.broadcom.com>
Date: Sat, 01 May 2010 16:19:43 +0200
Message-ID: <002c01cae939$5c01f400$1405dc00$@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: AcrimhyNUh3NLsf5RvSfcmuOhmvRfwBUwYUAAVLFoDA=
Content-Language: de
X-AntiVirus-Spam-Check: failed (checked by Avira MailGate: version: 3.0.0-4; spam filter version: unknown; host: mx05)
X-AntiVirus: checked by Avira MailGate (version: 3.0.0-4; AVE: 8.2.1.224; VDF: 7.10.7.16; host: mx05); id=318-GhXfty
Cc: codec@ietf.org
Subject: Re: [codec] #16: Multicast?
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: Sat, 01 May 2010 14:20:11 -0000

Hi Raymond,

>I would like to respond to a comment and a question in your original email below.
>
>(1) Regarding your comment that "per-instance RAM -- as long as
>it's reasonable -- is probably a bit less important than complexity", I think this may or may not be
>true depending on what is defined as "reasonable", and it also depends on the VoIP gateway under
>consideration. However, I think one thing is clear, though: per-instance RAM is definitely not
>unimportant.  I have worked in a team that designed high-density VoIP gateways, and I know people did
>all kinds of tricks to reduce the RAM usage as much as possible because of the high cost of the
>external high-speed SRAM used by high-speed DSPs in such gateways.
>
>Currently, high-density VoIP gateways can have several tens of thousands of voice channels per box or
>per equipment rack.  If codec A uses X kbytes more per-instance RAM than codec B, than implementing
>codec A rather than codec B in all channels will require X * (number of channels) more kbytes of high-
>speed SRAM, which can be a substantial additional cost.  Similarly, if codec A requires a
>substantially higher DSP MHz than codec B, then implementing codec A in all channels will mean that
>more high-speed DSP chips need to be used to maintain the same number of channels.  That's additional
>cost.  Actually, the more likely scenario is that the number of DSP chips has already maxed out due to
>board space or heat dissipation constraint, then the gateway can only support a substantially smaller
>number of voice channels when compared with using codec B.  Consequently, the channel density per box
>or per rack goes down substantially, and the per-channel deployment cost goes up substantially.  Thus,
>even if implementing codec A or codec B makes no practical difference in a PC, it can make a very real
>and substantial cost difference in VoIP gateways.

The arguments on costs of the gateways is raised often. Thus, it is worthwhile to consider in-depth.

May I ask you for more information about the design of VoIP Gateways. Particular, I am interested in the partition between audio
processing and protocol stack on DSP and CPU.

Does DSP take over all codec processing? May the CPU do some parts of the computation before, during or after DSP does the signal
processing?

How do you count number of channels? Do all voice channels have the same weight regardless their sampling rate?
Say suppose, if the mixing is done for 48kHz instead of 8kHz, how many resource are we allowed to consume more?

With best regards,

 Christian