Reducing Codecs Translation Time?

General Help
1

Hi All,
I get very unusually high translation time on all of my codecs, (I tried this on two different installations, one was a VM using AsteriskNOW 11.7 (CPU= 5GHz AMD), and the other one is a physical host where I compiled the whole thing from source code [Asterisk 13.5], (CPU = 2GHz Intel), both machines show unreasonably high translation time? Is there a way to reduce the codec translation time?
And by any change is there way to use Intel ipps to boost the codec translation?

CLI> core show translation recalc 60
Recalculating Codec Translation (number of sample seconds: 60)

     Translation times between formats (in microseconds) for one second of data
      Source Format (Rows) Destination Format (Columns)

       ulaw  alaw   gsm  g726 g726aal2 adpcm  slin  slin  slin  slin  slin  slin  slin  slin  slin lpc10  g729 speex speex speex  ilbc  g722 testlaw
 ulaw     -  9150 15000 15000    15000 15000  9000 17000 17000 17000 17000 17000 17000 17000 17000 15000 15000 15000 23000 23000 15000 17250   15000
 alaw  9150     - 15000 15000    15000 15000  9000 17000 17000 17000 17000 17000 17000 17000 17000 15000 15000 15000 23000 23000 15000 17250   15000
  gsm 15000 15000     - 15000    15000 15000  9000 17000 17000 17000 17000 17000 17000 17000 17000 15000 15000 15000 23000 23000 15000 17250   15000
 g726 15000 15000 15000     -    15000 15000  9000 17000 17000 17000 17000 17000 17000 17000 17000 15000 15000 15000 23000 23000 15000 17250   15000

g726aal2 15000 15000 15000 15000 - 15000 9000 17000 17000 17000 17000 17000 17000 17000 17000 15000 15000 15000 23000 23000 15000 17250 15000
adpcm 15000 15000 15000 15000 15000 - 9000 17000 17000 17000 17000 17000 17000 17000 17000 15000 15000 15000 23000 23000 15000 17250 15000
slin 6000 6000 6000 6000 6000 6000 - 8000 8000 8000 8000 8000 8000 8000 8000 6000 6000 6000 14000 14000 6000 8250 6000
slin 14500 14500 14500 14500 14500 14500 8500 - 8000 8000 8000 8000 8000 8000 8000 14500 14500 14500 14000 14000 14500 14000 14500
slin 14500 14500 14500 14500 14500 14500 8500 8500 - 8000 8000 8000 8000 8000 8000 14500 14500 14500 6000 14000 14500 6000 14500
slin 14500 14500 14500 14500 14500 14500 8500 8500 8500 - 8000 8000 8000 8000 8000 14500 14500 14500 14500 14000 14500 14500 14500
slin 14500 14500 14500 14500 14500 14500 8500 8500 8500 8500 - 8000 8000 8000 8000 14500 14500 14500 14500 6000 14500 14500 14500
slin 14500 14500 14500 14500 14500 14500 8500 8500 8500 8500 8500 - 8000 8000 8000 14500 14500 14500 14500 14500 14500 14500 14500
slin 14500 14500 14500 14500 14500 14500 8500 8500 8500 8500 8500 8500 - 8000 8000 14500 14500 14500 14500 14500 14500 14500 14500
slin 14500 14500 14500 14500 14500 14500 8500 8500 8500 8500 8500 8500 8500 - 8000 14500 14500 14500 14500 14500 14500 14500 14500
slin 14500 14500 14500 14500 14500 14500 8500 8500 8500 8500 8500 8500 8500 8500 - 14500 14500 14500 14500 14500 14500 14500 14500
lpc10 15000 15000 15000 15000 15000 15000 9000 17000 17000 17000 17000 17000 17000 17000 17000 - 15000 15000 23000 23000 15000 17250 15000
g729 15000 15000 15000 15000 15000 15000 9000 17000 17000 17000 17000 17000 17000 17000 17000 15000 - 15000 23000 23000 15000 17250 15000
speex 15000 15000 15000 15000 15000 15000 9000 17000 17000 17000 17000 17000 17000 17000 17000 15000 15000 - 23000 23000 15000 17250 15000
speex 23500 23500 23500 23500 23500 23500 17500 17500 9000 17000 17000 17000 17000 17000 17000 23500 23500 23500 - 23000 23500 15000 23500
speex 23500 23500 23500 23500 23500 23500 17500 17500 17500 17500 9000 17000 17000 17000 17000 23500 23500 23500 23500 - 23500 23500 23500
ilbc 15000 15000 15000 15000 15000 15000 9000 17000 17000 17000 17000 17000 17000 17000 17000 15000 15000 15000 23000 23000 - 17250 15000
g722 15600 15600 15600 15600 15600 15600 9600 17500 9000 17000 17000 17000 17000 17000 17000 15600 15600 15600 15000 23000 15600 - 15600
testlaw 15000 15000 15000 15000 15000 15000 9000 17000 17000 17000 17000 17000 17000 17000 17000 15000 15000 15000 23000 23000 15000 17250 -

2

Hi,

Probably you are using a 64 bit systems. In 64 bit systems the translation is calculated in microseconds and not in miliseconds. So, 15000 microseconds are 0.015 seconds (divided by 1,000,000). Of course there is still a lot to do to reduce it, but never the less this is the explanation. Here is a quote of Kevin Fleming from Digium:

This is why the output was changed to microseconds from milliseconds; in
the older version, the lowest number that should be shown was 1
millisecond, even if the actual amount of time consumed was 10
microseconds (or less). The “1” numbers in the output from the older
could easily have been “0.02”, which would be closer to the output from
the new version.

Thank you,

Daniel Friedman
Trixton LTD.

Mobile: +41.79.868.7050
Email: [email protected]

1 Like
3

oh, great, I think I need to get a pair of glasses :), I totally missed the fact that it had mentioned “microseconds” on the first line of the results. & you are right my systems are both 64bit.
Anyhow, while we are at it, can you plz kindly tell me if this results are ok (voice quality wise)? and how to tune them possibly?

my first policy is to avoid codec translation but time to time you might get cornered, & unfortunately each time I tested it I can sense the sound quality degrading and there are usually some flickering pauses here and there. it would be nice to get rid of them.
how can I get more realtime captured details on codec translation processes & their performance?

plus if by any chance translation module(s) can benefit from Intel® Integrated Performance Primitives (Intel® IPP) and its signal processing domain (IPPS)? (intel used to have this advertised that ipp can improve intel cpu performances on DSP and image processing & things like that … though they seem to obsolete their codec & speech processing domain on the new version 9 of IPP) but has anybody ever try to benchmark intel IPP on asterisk codec translation or its software echo cancelling modules?

-Seyed H. Mohajerani

4

Hi,

In order to get better results in the transcoding, I suggest you to test the Asterisk 1.8 version. I also get bad results on the newer versions of the Asterisk. If you want to use the IPP codec primitives, check this website:

[http://asterisk.hosting.lv/][1] [1]: http://asterisk.hosting.lv/ “http://asterisk.hosting.lv/”

I am pretty sure that you are already using it. Just keep in mind that this codec is not high quality for production systems. The only way to improve the transcoding values is to start participating in the code (dsp.c for example).

My suggestion is to avoid transcoding on production systems. If you do not have a bandwidth problem do not use compression on your voice streams. In a case that you have a bandwidth constrain, use a compression all the way.

Thank you,

Daniel Friedman