Re: [codec] #16: Multicast?

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

Hi Jean-Marc,

I would like to respond to a comment and a question in your original email below.

(1) Regarding your comment that "per-instance RAM -- as long as 
it's reasonable -- is probably a bit less important than complexity", I think this may or may not be true depending on what is defined as "reasonable", and it also depends on the VoIP gateway under consideration. However, I think one thing is clear, though: per-instance RAM is definitely not unimportant.  I have worked in a team that designed high-density VoIP gateways, and I know people did all kinds of tricks to reduce the RAM usage as much as possible because of the high cost of the external high-speed SRAM used by high-speed DSPs in such gateways.  

Currently, high-density VoIP gateways can have several tens of thousands of voice channels per box or per equipment rack.  If codec A uses X kbytes more per-instance RAM than codec B, than implementing codec A rather than codec B in all channels will require X * (number of channels) more kbytes of high-speed SRAM, which can be a substantial additional cost.  Similarly, if codec A requires a substantially higher DSP MHz than codec B, then implementing codec A in all channels will mean that more high-speed DSP chips need to be used to maintain the same number of channels.  That's additional cost.  Actually, the more likely scenario is that the number of DSP chips has already maxed out due to board space or heat dissipation constraint, then the gateway can only support a substantially smaller number of voice channels when compared with using codec B.  Consequently, the channel density per box or per rack goes down substantially, and the per-channel deployment cost goes up substantially.  Thus, even if implementing codec A or codec B makes no practical difference in a PC, it can make a very real and substantial cost difference in VoIP gateways.

An important application for the IETF codec is identified as "IPend-to-transcoding_gateway-to-PSTNend".  If the deployment cost of the IETF codec in the VoIP gateway is too high, that will limit the degree of such deployment, thus reducing the availability of such IP-to-PSTN calls and the usefulness of the IETF codec in this application scenario. 

(2) Regarding your question about the complexity requirement for the Bluetooth headset use case to be possible, for the current generation of low-end to mid-end Bluetooth mono headsets where most of the volume is, the 64 kb/s narrowband CVSD codec is universally used but is implemented in chip hardware and consumes no DSP or host processor cycles. (Many of them don't even have a DSP on chip and just have a host processor such as ARM7.)  All the processor cycles are being used by other tasks such as Bluetooth stack, echo control, noise suppression, packet loss concealment, etc.  Therefore, there actually aren't meaningful available processor cycles for a non-hardware-based codec unless we remove some other DSP functions or reduce their MHz consumption to make room for a firmware-implemented codec.

For the low- to mid-end Bluetooth headsets currently under development, the situation is not that much better.  Again we have to remove other functions or reduce their MHz usage to make room for a firmware-based codec.  Given such tight resources constraints, I would say ideally the full-duplex complexity of such a firmware-based codec should be no more than about 5 MHz on a typical 16-bit fixed-point DSP.  In a few years time, the acceptable MHz number may go up to 10 MHz, or at most 15 MHz.

Best Regards,

Raymond


-----Original Message-----
From: Jean-Marc Valin [mailto:[e-mail]] 
Sent: Thursday, April 22, 2010 9:05 PM
To: Raymond (Juin-Hwey) Chen
Cc: Christian Hoene; 'stephen botzko'; [e-mail]
Subject: Re: [codec] #16: Multicast?

Hi,

See me comments below.

> [Raymond]: High quality is a given, but I would like to emphasize the 
> importance of low latency.
>
> (1) It is well-known that the longer the latency, the lower the 
> perceived quality of the communication link. The E-model in the ITU-T 
> Recommendation G.107 models such communication quality in MOS_cqe, 
> which among other things depends on the so-called "delay impairment 
> factor" /Id/. Basically, MOS_cqe is a monotonically decreasing 
> function of increasing latency, and beyond about 150 ms one-way delay, 
> the perceived quality of the communication link drops rapidly with 
> further delay increase.
>

As the author of CELT, I obviously agree that latency is an important 
aspect for this codec :-) That being said, I tend to say that 20 ms is 
still the most widely used frame size, so we might as well optimise for 
that. This is not really a problem because as the frame size goes down, 
the overhead of the IP/UDP/RTP headers go up, so the codec bit-rate 
becomes a bit less of an issue. For example, with 5 ms frames, we would 
already be sending 64 kb/s worth of headers (excluding the link layer), 
so we might as well spend about as many bits on the actual payload as we 
spend on the headers. And with 64 kb/s of payload, we can actually have 
high-quality full-band audio.

> 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.

Definitely agree here. 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.

> 2) In topology b) of your other email 
> (IPend-to-transcoding_gateway-to-PSTNend), the transcoding gateway, or 
> VoIP gateway, often has to encode and decode thousands of voice 
> channels in a single box, so not only the computational complexity, 
> but also the per-instance RAM size requirement of the codec become 
> very important for achieving high channel density in the gateway.
>

Agreed here, although I would say that per-instance RAM -- as long as 
it's reasonable -- is probably a bit less important than complexity.

> 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.
>

Any idea what the complexity requirements would be for this use-case to 
be possible?

Cheers,

Jean-Marc