Re: [codec] #20: Computational complexity?

["Raymond (Juin-Hwey) Chen" <[e-mail]>]

Hi Christian,

(I changed the subject line to better reflect the nature of the email thread below...)

The ITU-T software tool library has been used to measure the complexity of many fixed-point standard speech codecs, and we have done that, too.  So, yes, I think it is a good and well-accepted way to measure the complexity of fixed-point codecs.

For floating-point implementations, although I don't know of a similar software tool for complexity measurement, it is not that difficult to do something similar and add some complexity counting code to an existing floating-point C code to measure the complexity of a floating-point codec.

Best Regards,

Raymond

-----Original Message-----
From: Christian Hoene [mailto:[e-mail]] 
Sent: Monday, May 10, 2010 11:00 PM
To: Raymond (Juin-Hwey) Chen; 'Jean-Marc Valin'
Cc: [e-mail]
Subject: RE: [codec] #16: Multicast?

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 [phone] 
http://www.net.uni-tuebingen.de/

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