Re: [codec] #16: Multicast?

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 332893A6767 for <>; Mon, 10 May 2010 15:06:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.438
X-Spam-Status: No, score=-1.438 tagged_above=-999 required=5 tests=[AWL=1.161, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6U2aJnoTfdOc for <>; Mon, 10 May 2010 15:06:31 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 41FEE3A6800 for <>; Mon, 10 May 2010 15:06:30 -0700 (PDT)
Received: from [] by with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Mon, 10 May 2010 15:06:02 -0700
X-Server-Uuid: 02CED230-5797-4B57-9875-D5D2FEE4708A
Received: from ([]) by ([]) with mapi; Mon, 10 May 2010 15:07:25 -0700
From: "Raymond (Juin-Hwey) Chen" <>
To: Jean-Marc Valin <>
Date: Mon, 10 May 2010 15:06:01 -0700
Thread-Topic: [codec] #16: Multicast?
Thread-Index: AcrwiGUjWbDe5NOHQqG6jJ5k6VuV9wABDfOQ
Message-ID: <>
References: <> <> <> <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: 67F65CC020S120734540-01-01
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Cc: "" <>
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 22:06:33 -0000

Hi Jean-Marc,

My email below was meant to be an additional note to my previous email and not as a reply to your first email today.  Sorry for the confusion.  

I hope my last email has answered your questions.

Best Regards,


-----Original Message-----
From: Jean-Marc Valin [] 
Sent: Monday, May 10, 2010 2:33 PM
To: Raymond (Juin-Hwey) Chen
Cc: Kevin P. Fleming;
Subject: Re: [codec] #16: Multicast?

Oh, I realise your original message did not state 10-20 MIPS as the target 
for all modes. My only questions was about how you came to the 10-20 MIPS 
figure in the first place. Any DSP vendor(s) roadmap or something? Or what 
would be the relevant existing DSP for which we could extrapolate future 
performance? As I said, I'm not too familiar about the DSPs used in 
Bluetooth because all the regular DSPs I can find are 50 MIPS or above.


Raymond (Juin-Hwey) Chen wrote:
> I should have clarified:
> I am not proposing that we limit the complexity of all IETF codec modes
> to 10 to 20 MIPS.  That would be unreasonable, especially for high-
> sampling-rate and high-fidelity applications.
> Just like we seemed to have reached a consensus that a low-delay mode
> is necessary to address delay-sensitive applications (as is specified
> in the codec requirement document), we can also have a low-complexity
> mode to address complexity-sensitive applications such as low-
> end/mobile devices and gateways. It is for such a low-complexity mode
> that 10 - 20 MIPS is a good target to shoot for, at least for
> narrowband and wideband. (Super-wideband and full-band can be layered
> coding on top of that and do not need to be subject to this 10 - 20
> MIPS target.) For other coding modes that require more processing
> power, this 10 - 20 MIPS target obviously would not apply.
> Also, if we don't like to have too many different coding modes, and if
> some modes can be combined, for example, if the low-delay mode can also
> achieve low complexity, then we can combine the low-delay mode and the
> low-complexity mode into a single mode.  We can have another mode
> that's more efficient in bit-rate but may have higher delay and
> complexity to address those applications that are less sensitive
> to delay and complexity.
> Raymond
> -----Original Message-----
> From: [] On Behalf Of Raymond (Juin-Hwey) Chen
> Sent: Monday, May 10, 2010 1:26 PM
> To: Kevin P. Fleming;
> Subject: Re: [codec] #16: Multicast?
> 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