Re: [codec] #20: Computational complexity?

["codec issue tracker" <[e-mail]>]

#20: Computational complexity?
------------------------------------+---------------------------------------
 Reporter:  hoene@…                 |       Owner:     
     Type:  defect                  |      Status:  new
 Priority:  major                   |   Milestone:     
Component:  requirements            |     Version:     
 Severity:  -                       |    Keywords:     
------------------------------------+---------------------------------------

Comment(by hoene@…):

 [Raymond]:

 > 3) Many telephone terminal devices at the edge of the Internet use
 > embedded processors with limited processing power, and the processors
 > also have to handle many tasks other than speech coding. If the IETF
 > codec complexity is too high, some of such devices may not have
 > sufficient processing power to run it. Even if the codec can fit, some
 > battery-powered mobile devices may prefer to run a lower-complexity
 > codec to reduce power consumption and battery drain. For example, even
 > if you make a Internet phone call from a computer, you may like the
 > convenience of using a Bluetooth headset that allows you to walk
 > around a bit and have hands-free operation. Currently most Bluetooth
 > headsets have small form factors with a tiny battery. This puts a
 > severe constraint on power consumption. Bluetooth headset chips
 > typically have very limited processing capability, and it has to
 > handle many other tasks such as echo cancellation and noise reduction.
 > There is just not enough processing power to handle a relatively
 > high-complexity codec. Most BT headsets today relies on the extremely
 > low-complexity, hardware-based CVSD codec at 64 kb/s to transmit
 > narrowband voice, but CVSD has audible coding noise, so it degrades
 > the overall audio quality. If the IETF codec has low enough
 > complexity, it would be possible to directly encode and decode the
 > IETF codec bit-stream at the BT headset, thus avoiding the quality
 > degradation of CVSD transcoding.

 [Koen]: By the time the BlueTooth Special Interest Group will have adopted
 a future IETF codec standard, Moore's law will surely have multiplied CPU
 resources in the BT device by one order of magnitude..?  Not sure it makes
 sense to apply today's BT constraints to tomorrow's codec.

 [Raymond]: Most importantly, guess what, in the last several years the
 Bluetooth headset chips have been growing its processing power at a MUCH,
 MUCH slower rate than what the Moore's Law says it should. Sometimes they
 did not increase the speed at all for years.  The reasons? The ASP
 (average sale price) of Bluetooth chips plummeted very badly, making it
 unattractive to invest significant resources to make them significantly
 faster.  Also, for low-end and mid-end BT headsets, the BT chips were
 often considered "good enough" and there wasn't a strong drive to increase
 the computing resources.  In addition, the BT headsets got smaller over
 the last few years; the corresponding reduction in battery size required a
 reduction in power consumption, which also limited how fast the processor
 speed could grow.  In the next several years, it is highly likely that the
 computing capabilities of Bluetooth headset chips will continue to grow at
 a rate substantially below what's predicted by the Moore's Law.

 [Raymond]: I would like to take this opportunity to express my view that
 although codec complexity isn’t much of an issue for PC-to-PC calls where
 there are GHz of processing power available, the codec complexity is an
 important issue in certain application scenarios. The following are just
 some examples.
 1) If a conference bridge has to decode a large number of voice channels,
 mix, and re-encode, and if compressed-domain mixing cannot be done (which
 is usually the case), then it is important to keep the decoder complexity
 low.

 [JM]: The decoder complexity is very important. Not only because of mixing
 issue, but also because the decoder is generally not allowed to take
 shortcuts to save on complexity (unlike the encoder). As for compressed-
 domain mixing, as you say it is not always available, but *if* we can do
 it (even if only partially), then that can result in a "free" reduction in
 decoder complexity for mixing.

 [Koen]: A codec/mode that meets the BT requirements for ultra-low
 complexity will have a relatively poor coding efficiency, resulting in
 lower audio quality and/or a higher bitrate.  Both of these negatively
 impact the user experience over the Internet.  Therefore, you do not want
 to run a BT codec over the Internet if you can use a more efficient codec
 instead.

 [Raymond]: Bluetooth headsets have much lower processing power and much
 smaller batteries than cell phones. The complexity of cellular codecs,
 typically in the range of 20 to 40 MHz on a DSP, is too high to fit most
 Bluetooth headsets. However, unlike cell phones and Bluetooth headsets
 where each is a specific type of device with a relatively narrow range of
 device complexity, Internet voice/audio applications can potentially
 encompass a large variety of different device types, from desktop
 computers at the high end with > 3 GHz multi-core CPU to IP phones and
 possibly even Bluetooth headsets at the low end with a processor of only a
 few tens of MHz.  It is up to the IETF codec WG how we want the complexity
 of the IETF codec to be.  We can standardize just one codec mode that
 works well for computer-to-computer calls but can't fit in low-end
 devices, or we can keep that mode but also have a low-complexity mode that
 can be implemented in low-end devices.

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/codec/trac/ticket/20#comment:1>
codec <http://tools.ietf.org/codec/>