CPU Requirements For Transcoding To/From G.729a
During the VOIP Users Conference call on December 14th someone made some claims about the ability to handle G.729a encoded calls on various platforms. The comments revolved around the significance of cpu cache when dealing with the G.729a codec. Also some claims of the ability to deal with very high numbers of calls. The claim about the numbers of simultaneous transcodes possible were troubling to me.
G.729a is one of the more complex codecs in the VOIP universe. It puts considerable load on the CPU of the system that must for whatever reason transcode the call. In particular it’s FPU intensive. While CPU architectures are deeply interesting to me, suffice it to say that on some hardware platforms floating point operations are amongst the slowest operations that a CPU may perform.
Of course transcoding is not always necessary. A call may be placed from a phone that is itself G.729a capable, through the local Asterisk instance to an ITSP and on to the recipient…all of which are also G.729a capable. The call can thus be made without any transcoding at all. However, at any point along the path the a stage may not accept G.729a stream and so the call gets transcoded into something more acceptable, perhaps G.711 or GSM. Most typically calls that get routed to voicemail are transcoded to G.711 for the VM subsystem, although not always. Asterisk always transcodes into G.711 for MeetMe conferences.
I know for a fact that the Soekris Net4801 embedded platform can handle two G.729a transcodes when suitable licenses are installed. I used this very arrangement for over a year, and even wrote an article about it here.
The Net4801 features a National Semiconductor Geode SC1100 CPU running at 266 MHz with an unspecified amount of cache. When I first started using G.729a on the Net4801 I inquired with Kristian Keilhofner, the lead author of Astlinux, about his experience with the board. Kristian told me that 2-3 simultaneous transcoded calls was the most I could expect due to CPU limitations. My own experience supports his assertion.
More recently I’m using a HP T5700 thin client which features a Transmeta Crusoe CPU running at 1 GHz and with 512 kb of L2 cache. Under test conditions I’ve had four G.729a transcodes ongoing on this platform, but my test was limited to having only four licenses installed. I suspect that it could handle a few more channels, but the CPU use with even four concurrent channels points to a hard limit perhaps around 10 channels. I may well test this myself some day soon should the need arise.
Finally, Digium’s TC400b PCI card is specifically built to accelerate transcoding and offload that task from the host CPU. According to Digium, “The TC400B is rated to handle up to 96 bi-directional G.729a transformations or 92 bi-directional G.723.1 transformations.” If this is the stated capability of their accelerator then it seems unreasonable to expect similar or greater performance from a small format embedded platform, whatever the CPU cache might be.
The statements mentioned previously indicated the potential for a dramatically larger number of transcoded calls than would seem to be possible on the given platform. I find this unlikely on the basis of personal experience, the opinion of others whom I respect and Digium’s own statements about their transcoding hardware.
If you need transcoding capability on a low cost embedded platform it can’t hurt to consult with sources you trust. Ultimately you should conduct your own testing to be certain that the hardware supports your requirements reliably under real-world circumstances.
Comments are closed.
Hi,
This is interesting, but what’s the application here for transcoding G729a on small, low-powered boxes? Hardware solutions such as the TC400b aren’t necessarily better in the days of cheap server hardware. In practise, we see very few customers requesting G726a.
James
At least in my experience the application is managing bandwidth when using ITSPs. If you need to make VOIP calls over DSL then conservation of outbound bandwidth is a make or break issue. As you note, if POTS lines are your primary calling channel it won’t matter nearly as much.
Early in my use of Asterisk I tried just about every small format FXO adapter that was available at the time. I decided none were acceptable for a variety of reasons. Combine that with my aversion to AT&T, the only ILEC in my area, and I decided to go wholly VOIP. Not POTS lines left at all. That was 18 months ago.
This provided the motivation to learn about the specifics of codecs, traffic shaping and QoS. Each of which is important in its own way.
From a purely technical point of view it’s worth noting that G.729a (and most other ITU codecs) have a fixed point implementation which gives bit-for-bit correct results against the ITU test sets. Indeed, a conventional “C”, i.e. floating point implementation, is likely to be only approximately correct (against the ITU test sets).
Second, if you really want a high performance implementation on a general purpose CPU, many such CPUs (certainly Intel architecture and Power PC CPUs) include specialized instruction sets which optimize vector arithmetic for digital signal processing algorithms audio codecs and video manipulation. Using such instructions it is quite feasible to get 50-100 channels of G.729a transcoding on a dual 3.2GHz Xeon (IA) box.
Of course that takes a lot of work from a DSP nerd… 🙂
Many thanks for the commentary. The posting was inspired by a comment on VOIP Users Conference Call with respect to low cost, small form factor embedded systems with limited CPU capacity. The kinds of hardware that we see the emerging Asterisk appliances (Digium, Xorcom, etc) leveraging. I just thought it worth clarifying that many (say 50+) channels of tanscoding on such hardware was not very likely.
Of course there are larger systems available that call themselves “appliances”, for example http://www.asteriskvoipnews.com/asterisk_hardware/trixbox_asterisk_appliance.html. These use more traditional server class hardware and so would have considerably greater capabilities.
These don’t really meet my personal definition of an embedded system for the SOHO market.
I would be very interested in finding out where Digium is finding demand for their TC400b transcoding accelerator.
Thanks!
Hi
As you’ve given nice info about G.729a codec, i was just wondering whether G.729ab / G.729b are the same? if no they can also handle high no of calls.
I also tried to find out the difference with pros & cons at http://speechcodecs.wordpress.com/ but i didn’t get it clearly. may be u can elaborate it.
My recollection is that one form of the codec is much less common that the other. The voip wiki at http://www.voip-info.org references the ITU documents at http://www.itu.int/rec/T-REC-G.729-200701-I/en.