Re: [codec] #16: Multicast?

"Christian Hoene" <> Tue, 11 May 2010 06:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 37C1C28C122 for <>; Mon, 10 May 2010 23:00:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jy7QmLd--TLR for <>; Mon, 10 May 2010 23:00:04 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E3F403A6AE0 for <>; Mon, 10 May 2010 23:00:03 -0700 (PDT)
Received: from hoeneT60 ([]) (authenticated bits=0) by (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 <>
To: "'Raymond (Juin-Hwey) Chen'" <>, 'Jean-Marc Valin' <>
References: <> <002d01cae188$a330b2c0$e9921840$@de> <> <> <> <002c01cae939$5c01f400$1405dc00$@de> <>, <009901caede1$43f366d0$cbda3470$@de> <> <> <> <> <> <> <> <> <> <! CB68DF4CFBEF4942881AD37>
In-Reply-To: <>
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)
Subject: Re: [codec] #16: Multicast?
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Codec WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 11 May 2010 06:00:06 -0000


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.
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,


Dr.-Ing. Christian Hoene
Interactive Communication Systems (ICS), University of Tübingen 
Sand 13, 72076 Tübingen, Germany, Phone +49 7071 2970532

>-----Original Message-----
>From: [] On Behalf Of Raymond (Juin-Hwey) Chen
>Sent: Tuesday, May 11, 2010 12:03 AM
>To: Jean-Marc Valin
>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.
>-----Original Message-----
>From: Jean-Marc Valin []
>Sent: Monday, May 10, 2010 1:50 PM
>To: Raymond (Juin-Hwey) Chen
>Cc: Kevin P. Fleming;
>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?
>	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: [] On Behalf Of Kevin P. Fleming
>> Sent: Monday, May 10, 2010 12:33 PM
>> To:
>> 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:
>> Check us out at &
>> _______________________________________________
>> codec mailing list
>> _______________________________________________
>> codec mailing list
>codec mailing list