Re: [codec] #16: Multicast?

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

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