Re: [codec] #16: Multicast?

"Christian Hoene" <hoene@uni-tuebingen.de> Tue, 11 May 2010 06:00 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 37C1C28C122 for <codec@core3.amsl.com>; Mon, 10 May 2010 23:00:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.335
X-Spam-Level: *
X-Spam-Status: No, score=1.335 tagged_above=-999 required=5 tests=[AWL=-5.373, BAYES_50=0.001, FM_VIAGRA_SPAM1114=10.357, 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 jy7QmLd--TLR for <codec@core3.amsl.com>; Mon, 10 May 2010 23:00:04 -0700 (PDT)
Received: from mx06.uni-tuebingen.de (mx06.uni-tuebingen.de [134.2.3.3]) by core3.amsl.com (Postfix) with ESMTP id E3F403A6AE0 for <codec@ietf.org>; Mon, 10 May 2010 23:00:03 -0700 (PDT)
Received: from hoeneT60 ([178.2.215.148]) (authenticated bits=0) by mx06.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id o4B5xeiI013108 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 11 May 2010 07:59:46 +0200
From: Christian Hoene <hoene@uni-tuebingen.de>
To: "'Raymond (Juin-Hwey) Chen'" <rchen@broadcom.com>, 'Jean-Marc Valin' <jean-marc.valin@octasic.com>
References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <002d01cae188$a330b2c0$e9921840$@de> <CB68DF4CFBEF4942881AD37AE1A7E8C74AB3F4A017@IRVEXCHCCR01.corp.ad.broadcom.com> <4BD11C50.2020206@usherbrooke.ca> <CB68DF4CFBEF4942881AD37AE1A7E8C74AB3F4A287@IRVEXCHCCR01.corp.ad.broadcom.com> <002c01cae939$5c01f400$1405dc00$@de> <CB68DF4CFBEF4942881AD37AE1A7E8C74B903454B3@IRVEXCHCCR01.corp.ad.broadcom.com>, <009901caede1$43f366d0$cbda3470$@de> <BCB3F026FAC4C145A4A3330806FEFDA93AB072BCC6@EMBX01-HQ.jnpr.net> <CB68DF4CFBEF4942881AD37AE1A7E8C74B90345C0D@IRVEXCHCCR01.corp.ad.broadcom.com> <20100507144856.171013mxhy3wdfbc@mail.skype.net> <CB68DF4CFBEF4942881AD37AE1A7E8C74B90345CCF@IRVEXCHCCR01.corp.ad.broadcom.com> <20100509143636.21296os5ryogl1ic@mail.skype.net> <CB68DF4CFBEF4942881AD37AE1A7E8C74B90345E38@IRVEXCHCCR01.corp.ad.broadcom.com> <4BE85F57.9040205@digium.com> <CB68DF4CFBEF4942881AD37AE1A7E8C74B90345E7D@IRVEXCHCCR01.corp.ad.broadcom.com> <4BE87165.2030401@octasic.com> <! CB68DF4CFBEF4942881AD37 AE1A7E8C74B90345F0A@IRVEXCHCCR01.corp.ad.broadcom.com>
In-Reply-To: <CB68DF4CFBEF4942881AD37AE1A7E8C74B90345F0A@IRVEXCHCCR01.corp.ad.broadcom.com>
Date: Tue, 11 May 2010 07:59:32 +0200
Message-ID: <000001caf0cf$282a2e70$787e8b50$@de>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcrwglZlRdRMon4wRWWDChT4kHf3/QABZ4egABF0sYA=
Content-Language: de
X-AntiVirus: NOT checked by Avira MailGate (version: 3.0.0-4; host: mx06)
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: Tue, 11 May 2010 06:00:06 -0000

Hello,

what do you think about STL2005/9 described in ITU-T G.191. It might be a good metric to measure the codec performance in
low-complexity mode. STL2009 is not yet published officially but the STL 2005 manual is available for free.
http://www.itu.int/rec/T-REC-G.191-200508-I/en
Chapter 13, Page 159 describes a set of basic operator and their complexity weights. STL2009 is similar but has guidelines on data
movement and program ROM estimation tool for fixed-point c code and a complexity evaluation tool for floating-point C Code.

However, STL2005 might not be optimal for soft-phone complexity prediction because many operations have overflow control and
saturation, that typically cannot be translated into a single native assembler instruction. Thus, for soft-phone I would recommend
to use slightly modified measures...

With best regards,

 Christian


---------------------------------------------------------------
Dr.-Ing. Christian Hoene
Interactive Communication Systems (ICS), University of Tübingen 
Sand 13, 72076 Tübingen, Germany, Phone +49 7071 2970532 
http://www.net.uni-tuebingen.de/

>-----Original Message-----
>From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of Raymond (Juin-Hwey) Chen
>Sent: Tuesday, May 11, 2010 12:03 AM
>To: Jean-Marc Valin
>Cc: codec@ietf.org
>Subject: Re: [codec] #16: Multicast?
>
>Hi Jean-Marc,
>
>I didn't just cook up those MIPS numbers out of my head :o)  I have been working with Bluetooth
>engineers on voice/audio processing for Bluetooth headsets in the last few years.
>
>Bluetooth headsets normally don't use general-purpose DSPs from those traditional DSP houses that you
>mentioned below.  A lot of mid- to low-end Bluetooth headsets (where most of the shipping volume is)
>don't even have any DSP and instead just rely on an ARM processor to do all voice/audio processing and
>Bluetooth protocol stack.  The 5 MIPS number for current-generation BT headsets was quoted to me by an
>experienced Bluetooth audio engineering manager in terms of MIPS on an ARM processor, but since most
>speech coding engineers are more familiar with the MIPS for a general-purpose 16-bit fixed-point DSP,
>so I converted the MIPS on an ARM to the equivalent MIPS on a fixed-point DSP, and it came to around 5
>MIPS.  The 10 to 20 MIPS number is what we may expect in a several years as Moore's Law helps to
>increase the processing power of Bluetooth headsets.
>
>High-end Bluetooth headset chips may have a DSP on-chip, but it is usually either a proprietary DSP or
>a DSP core not from the traditional DSP houses but from companies like ARM.
>
>One thing to keep in mind, though, is that even if you have a DSP on a Bluetooth headset chip, and it
>is clocked at 50 MHz or higher, it doesn't mean that you can use all or most of that DSP processing
>power for speech or audio coding.  This is because it has to handle many other signal processing tasks
>such as acoustic echo canceller, single-mic or multi-mic noise suppression, wind noise suppression,
>packet loss concealment, voice prompt decoding, and even voice command recognition, to name just a
>few.  You can't even get half of the DSP processing power solely dedicated to speech coding.  You will
>be lucky if you can get 20% of the DSP for speech coding.  Remember that currently the speech coding
>part (CVSD codec) takes 0% of the DSP or ARM because it is done in chip hardware.
>
>Raymond
>
>-----Original Message-----
>From: Jean-Marc Valin [mailto:jean-marc.valin@octasic.com]
>Sent: Monday, May 10, 2010 1:50 PM
>To: Raymond (Juin-Hwey) Chen
>Cc: Kevin P. Fleming; codec@ietf.org
>Subject: Re: [codec] #16: Multicast?
>
>Hi Raymond,
>
>I'm just curious about where you got your MIPS figures for Bluetooth? I'm
>not familiar with the type of DSPs used in those applications, but from a
>quick search of more "general-purpose" DSPs (TI, ADI and similar), the
>lowest speed I was able to find (sold in 2010) was a 50 MIPS DSP. Any idea
>what type of DSPs are currently used in Bluetooth?
>
>Cheers,
>
>	Jean-Marc
>
>Raymond (Juin-Hwey) Chen wrote:
>> Hi Kevin,
>>
>> I completely agree with you that the IETF codec development should not
>> be constrained by a low-complexity device designed in 2009 or earlier,
>> and we should look toward the time frame of 2012 and 2013 instead.
>>
>> In my previous emails I have indicated that due to many reasons, over
>> the last several years the processing power of Bluetooth headsets has
>> been increasing at a rate much slower than what's predicted by Moore's
>> Law, and it doesn't look like this will change significantly in the next
>> few years.  I also said that for the current-generation Bluetooth
>> headset chips, the maximum codec complexity it can support is probably
>> somewhere around 5 MIPS on a 16-bit fixed-point DSP, and by the time the
>> IETF codec becomes a standard, the number may go up to 10 MIPS, or 15
>> MIPS at most.
>>
>> Thus, if we want mono Bluetooth headsets in the FUTURE (i.e. in the next
>> several years) to be able to run the IETF codec in the narrowband or
>> wideband mode at least, a good complexity target to shoot for is 10 to
>> 20 MIPS on a fixed-point DSP.
>>
>> Raymond
>>
>> -----Original Message-----
>> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of Kevin P. Fleming
>> Sent: Monday, May 10, 2010 12:33 PM
>> To: codec@ietf.org
>> Subject: Re: [codec] #16: Multicast?
>>
>> On 05/10/2010 02:11 PM, Raymond (Juin-Hwey) Chen wrote:
>>
>>> Considering that there are a very large number of Bluetooth headset users and that the current
>Bluetooth headsets can already be used for making VoIP phone calls, it would be great if the IETF
>codec can be implemented in future Bluetooth headsets to avoid the additional coding distortion and
>delay associated with transcoding. However, with that said, I didn't mean to push a "Bluetooth mode"
>for the IETF codec. I merely wanted to use Bluetooth headset as an example to make a point that a low
>codec complexity is desirable and a high codec complexity can have negative consequences.
>>
>> This is all perfectly reasonable, but given the likely timeframe we are
>> talking about for this codec to be produced and published as a
>> standards-track RFC, the definition of 'low complexity' in this
>> discussion is really talking about the 2012-2013 version of 'low
>> complexity', not today's. It seems highly likely that the MIPS capacity
>> of the DSPs designed into Bluetooth headsets in 2012 will be vastly
>> greater than what is used today, if there is an application to take
>> advantage of the additional MIPS.
>>
>> I'd hate to see this codec's development constrained in any significant
>> way by the requirements of a low-complexity device designed in 2009 or
>> earlier.
>>
>> --
>> Kevin P. Fleming
>> Digium, Inc. | Director of Software Technologies
>> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
>> skype: kpfleming | jabber: kfleming@digium.com
>> Check us out at www.digium.com & www.asterisk.org
>> _______________________________________________
>> codec mailing list
>> codec@ietf.org
>> https://www.ietf.org/mailman/listinfo/codec
>>
>>
>> _______________________________________________
>> codec mailing list
>> codec@ietf.org
>> https://www.ietf.org/mailman/listinfo/codec
>
>
>
>_______________________________________________
>codec mailing list
>codec@ietf.org
>https://www.ietf.org/mailman/listinfo/codec