Re: [codec] #20: Computational complexity?
"Raymond (Juin-Hwey) Chen" <rchen@broadcom.com> Wed, 12 May 2010 00:17 UTC
Return-Path: <rchen@broadcom.com>
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 A24C63A6C14 for <codec@core3.amsl.com>; Tue, 11 May 2010 17:17:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.935
X-Spam-Level:
X-Spam-Status: No, score=0.935 tagged_above=-999 required=5 tests=[AWL=-1.232, BAYES_50=0.001, FF_IHOPE_YOU_SINK=2.166]
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 kF-PKeFaEzto for <codec@core3.amsl.com>; Tue, 11 May 2010 17:17:45 -0700 (PDT)
Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by core3.amsl.com (Postfix) with ESMTP id 1BB3F3A6AA9 for <codec@ietf.org>; Tue, 11 May 2010 17:17:45 -0700 (PDT)
Received: from [10.9.200.133] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Tue, 11 May 2010 17:17:24 -0700
X-Server-Uuid: 02CED230-5797-4B57-9875-D5D2FEE4708A
Received: from IRVEXCHCCR01.corp.ad.broadcom.com ([10.252.49.31]) by IRVEXCHHUB02.corp.ad.broadcom.com ([10.9.200.133]) with mapi; Tue, 11 May 2010 17:18:47 -0700
From: "Raymond (Juin-Hwey) Chen" <rchen@broadcom.com>
To: Christian Hoene <hoene@uni-tuebingen.de>, 'Jean-Marc Valin' <jean-marc.valin@octasic.com>
Date: Tue, 11 May 2010 17:17:22 -0700
Thread-Topic: [codec] #20: Computational complexity?
Thread-Index: AcrwglZlRdRMon4wRWWDChT4kHf3/QABZ4egABF0sYAAJg33cA==
Message-ID: <CB68DF4CFBEF4942881AD37AE1A7E8C74B90346246@IRVEXCHCCR01.corp.ad.broadcom.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> <000001caf0cf$282a2e70$787e8b50$@de>
In-Reply-To: <000001caf0cf$282a2e70$787e8b50$@de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
MIME-Version: 1.0
X-WSS-ID: 67F72C1E20S122033864-01-01
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: "codec@ietf.org" <codec@ietf.org>
Subject: Re: [codec] #20: Computational complexity?
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: Wed, 12 May 2010 00:17:46 -0000
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:hoene@uni-tuebingen.de] Sent: Monday, May 10, 2010 11:00 PM To: Raymond (Juin-Hwey) Chen; 'Jean-Marc Valin' Cc: codec@ietf.org 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 +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
- [codec] #16: Multicast? codec issue tracker
- Re: [codec] #16: Multicast? Colin Perkins
- Re: [codec] #16: Multicast? Christian Hoene
- Re: [codec] #16: Multicast? Marshall Eubanks
- Re: [codec] #16: Multicast? stephen botzko
- Re: [codec] #16: Multicast? Colin Perkins
- Re: [codec] #16: Multicast? Colin Perkins
- Re: [codec] #16: Multicast? stephen botzko
- Re: [codec] #16: Multicast? Christian Hoene
- Re: [codec] #16: Multicast? stephen botzko
- Re: [codec] #16: Multicast? Marshall Eubanks
- Re: [codec] #16: Multicast? Christian Hoene
- Re: [codec] #16: Multicast? stephen botzko
- Re: [codec] #16: Multicast? Christian Hoene
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Jean-Marc Valin
- Re: [codec] #16: Multicast? Koen Vos
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Mikael Abrahamsson
- Re: [codec] #16: Multicast? Jean-Marc Valin
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Koen Vos
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? stephen botzko
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Koen Vos
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Mikael Abrahamsson
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Mikael Abrahamsson
- Re: [codec] #16: Multicast? (Bluetooth) Koen Vos
- Re: [codec] #16: Multicast? Koen Vos
- Re: [codec] #16: Multicast? stephen botzko
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Koen Vos
- Re: [codec] #16: Multicast? (Bluetooth) Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? (Bluetooth) stephen botzko
- Re: [codec] #16: Multicast? Christian Hoene
- Re: [codec] #16: Multicast? Christian Hoene
- Re: [codec] #16: Multicast? Christian Hoene
- Re: [codec] #16: Multicast? (USB) Roni Even
- Re: [codec] #16: Multicast? codec issue tracker
- Re: [codec] #16: Multicast? stephen botzko
- Re: [codec] #16: Multicast? Cullen Jennings
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Mikael Abrahamsson
- Re: [codec] #16: Multicast? Koen Vos
- Re: [codec] #16: Multicast? (Bluetooth) Koen Vos
- Re: [codec] #16: Multicast? stephen botzko
- Re: [codec] #16: Multicast? Christian Hoene
- Re: [codec] #19: How large is the frame size depe… Christian Hoene
- Re: [codec] #19: How large is the frame size depe… stephen botzko
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #19: How large is the frame size depe… Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? (Bluetooth) Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? stephen botzko
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? stephen botzko
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Koen Vos
- Re: [codec] #16: Multicast? Christian Hoene
- Re: [codec] #16: Multicast? Gregory Maxwell
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Koen Vos
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Koen Vos
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Koen Vos
- Re: [codec] #16: Multicast? Koen Vos
- Re: [codec] #16: Multicast? Benjamin M. Schwartz
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Kevin P. Fleming
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Jean-Marc Valin
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Jean-Marc Valin
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Christian Hoene
- Re: [codec] #16: Multicast? Koen Vos
- Re: [codec] #16: Multicast? Christian Hoene
- Re: [codec] #16: Multicast? Ben Schwartz
- Re: [codec] #16: Multicast? Marshall Eubanks
- Re: [codec] #16: Multicast? Brian Rosen
- Re: [codec] #16: Multicast? Christian Hoene
- Re: [codec] #16: Multicast? Jean-Marc Valin
- Re: [codec] Thresholds and delay. Ben Schwartz
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] Thresholds and delay. stephen botzko
- Re: [codec] #16: Multicast? Christian Hoene
- Re: [codec] Thresholds and delay. Ben Schwartz
- Re: [codec] #20: Computational complexity? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] Thresholds and delay. jari.hagqvist
- Re: [codec] Thresholds and delay. stephen botzko
- Re: [codec] Thresholds and delay. Ben Schwartz
- Re: [codec] Thresholds and delay. Marshall Eubanks
- Re: [codec] Thresholds and delay. stephen botzko
- Re: [codec] #16: Multicast? Cullen Jennings
- Re: [codec] Thresholds and delay. Michael Knappe
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Koen Vos
- Re: [codec] #16: Delay factor: algorithmic delay … Christian Hoene
- Re: [codec] #16: Delay factor: algorithmic delay … Mikael Abrahamsson
- Re: [codec] #16: Delay factor: algorithmic delay … Roman Shpount
- Re: [codec] #16: Delay factor: algorithmic delay … stephen botzko
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Cullen Jennings
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Koen Vos
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Koen Vos
- Re: [codec] #16: Multicast? Christian Hoene
- Re: [codec] #16: Multicast? Jean-Marc Valin
- Re: [codec] #16: Multicast? Herve Taddei
- Re: [codec] #16: Multicast? Christian Hoene
- Re: [codec] #16: Multicast? Jean-Marc Valin
- Re: [codec] #16: Multicast? Sandy (Alexander) MacInnis
- Re: [codec] #16: Multicast? Christian Hoene
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Roman Shpount
- Re: [codec] #16: Multicast? Herve Taddei
- Re: [codec] #16: Multicast? Cullen Jennings
- [codec] Suggested summary... Christian Hoene
- Re: [codec] Suggested summary... stephen botzko
- Re: [codec] Suggested summary... Herve Taddei
- Re: [codec] Suggested summary... Christian Hoene
- Re: [codec] Suggested summary... Michael Knappe
- Re: [codec] Suggested summary... Herve Taddei
- Re: [codec] Suggested summary... stephen botzko
- Re: [codec] Suggested summary... Christian Hoene
- Re: [codec] Suggested summary... Christian Hoene
- Re: [codec] Suggested summary... stephen botzko
- Re: [codec] Suggested summary... Raymond (Juin-Hwey) Chen
- Re: [codec] Suggested summary... Christian Hoene
- Re: [codec] Suggested summary... Herve Taddei
- Re: [codec] Suggested summary... Raymond (Juin-Hwey) Chen