Re: [codec] #16: Multicast?

"Raymond (Juin-Hwey) Chen" <> Mon, 10 May 2010 20:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DFCD63A6964 for <>; Mon, 10 May 2010 13:35:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.198
X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[AWL=-0.013, BAYES_40=-0.185]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3UiyKOk5hxGd for <>; Mon, 10 May 2010 13:35:06 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2D3E63A6C3A for <>; Mon, 10 May 2010 13:26:25 -0700 (PDT)
Received: from [] by with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Mon, 10 May 2010 13:26:00 -0700
X-Server-Uuid: 02CED230-5797-4B57-9875-D5D2FEE4708A
Received: from ([]) by ([]) with mapi; Mon, 10 May 2010 13:26:00 -0700
From: "Raymond (Juin-Hwey) Chen" <>
To: "Kevin P. Fleming" <>, "" <>
Date: Mon, 10 May 2010 13:25:59 -0700
Thread-Topic: [codec] #16: Multicast?
Thread-Index: AcrweSYx81GgbVfnTFaPGSA5qPSCxQAAhvrw
Message-ID: <>
References: <> <001101cae177$e8aa6780$b9ff3680$@de> <> <002d01cae188$a330b2c0$e9921840$@de> <> <> <> <002c01cae939$5c01f400$1405dc00$@de> <>, <009901caede1$43f366d0$cbda3470$@de> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
MIME-Version: 1.0
X-WSS-ID: 67F6B45220S120652012-01-01
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
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: Mon, 10 May 2010 20:35:08 -0000

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.


-----Original Message-----
From: [] On Behalf Of Kevin P. Fleming
Sent: Monday, May 10, 2010 12:33 PM
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

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