Asterisk 10.7 slow codec translation

Asterisk Asterisk Support
1

Hi!

On the same hardware Asterisk 10.7.1 shows about 10 times slower codec translation then Asterisk 1.8.15. The ulaw->gsm translation takes 15000 microseconds on 10.7.1 versus 1600 microseconds on 1.8.15.1.

Is it possible to speed up 10.7?

Sincerely
Dmitry

ast10xCLI> core show version
Asterisk 10.7.1 built by root @ 92-139-19-10.digium.internal on a i686 running Linux on 2012-08-31 19:09:49 UTC
ast10xCLI> core show translation recalc 10
Recalculating Codec Translation (number of sample seconds: 10)

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

        gsm  ulaw  alaw  g726 adpcm  slin lpc10  ilbc g726aal2  g722 slin16 testlaw
  gsm     - 15000 15000 15000 15000  9000 15000 15000    15000 17250  26250   15000
 ulaw 15000     -  9150 15000 15000  9000 15000 15000    15000 17250  26250   15000
 alaw 15000  9150     - 15000 15000  9000 15000 15000    15000 17250  26250   15000
 g726 15000 15000 15000     - 15000  9000 15000 15000    15000 17250  26250   15000
adpcm 15000 15000 15000 15000     -  9000 15000 15000    15000 17250  26250   15000
 slin  6000  6000  6000  6000  6000     -  6000  6000     6000  8250  17250    6000
lpc10 15000 15000 15000 15000 15000  9000     - 15000    15000 17250  26250   15000
 ilbc 15000 15000 15000 15000 15000  9000 15000     -    15000 17250  26250   15000

g726aal2 15000 15000 15000 15000 15000 9000 15000 15000 - 17250 26250 15000
g722 15600 15600 15600 15600 15600 9600 15600 15600 15600 - 9000 15600
slin16 21600 21600 21600 21600 21600 15600 21600 21600 21600 6000 - 21600
testlaw 15000 15000 15000 15000 15000 9000 15000 15000 15000 17250 26250 -

ast018CLI> core show version
Asterisk 1.8.15.1 built by root @ 92-139-19-10.digium.internal on a i686 running Linux on 2012-08-31 18:57:50 UTC
ast018CLI> core show translation recalc 10
Recalculating Codec Translation (number of sample seconds: 10)

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

       g723   gsm  ulaw  alaw g726aal2 adpcm  slin lpc10  g729 speex  ilbc  g726  g722 siren7 siren14 slin16  g719 speex16 testlaw
 g723     -     -     -     -        -     -     -     -     -     -     -     -     -      -       -      -     -       -       -
  gsm     -     -   500   599     2698   699   499  3098     -     -  9397  2598  1198      -       -   2197     -       -     599
 ulaw     -  1600     -     1     2200   201     1  2600     -     -  8899  2100   700      -       -   1699     -       -     101
 alaw     -  1600     1     -     2200   201     1  2600     -     -  8899  2100   700      -       -   1699     -       -     101

g726aal2 - 2398 800 899 - 999 799 3398 - - 9697 2898 1498 - - 2497 - - 899
adpcm - 1699 101 200 2299 - 100 2699 - - 8998 2199 799 - - 1798 - - 200
slin - 1599 1 100 2199 200 - 2599 - - 8898 2099 699 - - 1698 - - 100
lpc10 - 2898 1300 1399 3498 1499 1299 - - - 10197 3398 1998 - - 2997 - - 1399
g729 - - - - - - - - - - - - - - - - - - -
speex - - - - - - - - - - - - - - - - - - -
ilbc - 3198 1600 1699 3798 1799 1599 4198 - - - 3698 2298 - - 3297 - - 1699
g726 - 2398 800 899 2998 999 799 3398 - - 9697 - 1498 - - 2497 - - 899
g722 - 2398 800 899 2998 999 799 3398 - - 9697 2898 - - - 999 - - 899
siren7 - - - - - - - - - - - - - - - - - - -
siren14 - - - - - - - - - - - - - - - - - - -
slin16 - 3797 2199 2298 4397 2398 2198 4797 - - 11096 4297 1399 - - - - - 2298
g719 - - - - - - - - - - - - - - - - - - -
speex16 - - - - - - - - - - - - - - - - - - -
testlaw - 1600 2 101 2200 201 1 2600 - - 8899 2100 700 - - 1699 - - -
ast018*CLI>

2

I have the exact same issue with v. 10.10 and also 11.1.2. With 1.8.x versions I was getting 1 microsec etc between common codecs like ulaw, alaw, gsm, but now VERY long times. Times on all machines are in microseconds as all machines run in 64bit mode.

Anyone?

            gsm  ulaw  alaw  g726 adpcm  slin lpc10  ilbc g726aal2  g722 slin16 testlaw slin12 slin24 slin32 slin44 slin48 slin96 slin192
      gsm     - 15000 15000 15000 15000  9000 15000 15000    15000 17250  17000   15000  17000  17000  17000  17000  17000  17000   17000
     ulaw 15000     -  9150 15000 15000  9000 15000 15000    15000 17250  17000   15000  17000  17000  17000  17000  17000  17000   17000
     alaw 15000  9150     - 15000 15000  9000 15000 15000    15000 17250  17000   15000  17000  17000  17000  17000  17000  17000   17000
     g726 15000 15000 15000     - 15000  9000 15000 15000    15000 17250  17000   15000  17000  17000  17000  17000  17000  17000   17000
    adpcm 15000 15000 15000 15000     -  9000 15000 15000    15000 17250  17000   15000  17000  17000  17000  17000  17000  17000   17000
     slin  6000  6000  6000  6000  6000     -  6000  6000     6000  8250   8000    6000   8000   8000   8000   8000   8000   8000    8000
    lpc10 15000 15000 15000 15000 15000  9000     - 15000    15000 17250  17000   15000  17000  17000  17000  17000  17000  17000   17000
     ilbc 15000 15000 15000 15000 15000  9000 15000     -    15000 17250  17000   15000  17000  17000  17000  17000  17000  17000   17000
 g726aal2 15000 15000 15000 15000 15000  9000 15000 15000        - 17250  17000   15000  17000  17000  17000  17000  17000  17000   17000
     g722 15600 15600 15600 15600 15600  9600 15600 15600    15600     -   9000   15600  17500  17000  17000  17000  17000  17000   17000
   slin16 14500 14500 14500 14500 14500  8500 14500 14500    14500  6000      -   14500   8500   8000   8000   8000   8000   8000    8000
  testlaw 15000 15000 15000 15000 15000  9000 15000 15000    15000 17250  17000       -  17000  17000  17000  17000  17000  17000   17000
   slin12 14500 14500 14500 14500 14500  8500 14500 14500    14500 14000   8000   14500      -   8000   8000   8000   8000   8000    8000
   slin24 14500 14500 14500 14500 14500  8500 14500 14500    14500 14500   8500   14500   8500      -   8000   8000   8000   8000    8000
   slin32 14500 14500 14500 14500 14500  8500 14500 14500    14500 14500   8500   14500   8500   8500      -   8000   8000   8000    8000
   slin44 14500 14500 14500 14500 14500  8500 14500 14500    14500 14500   8500   14500   8500   8500   8500      -   8000   8000    8000
   slin48 14500 14500 14500 14500 14500  8500 14500 14500    14500 14500   8500   14500   8500   8500   8500   8500      -   8000    8000
   slin96 14500 14500 14500 14500 14500  8500 14500 14500    14500 14500   8500   14500   8500   8500   8500   8500   8500      -    8000
  slin192 14500 14500 14500 14500 14500  8500 14500 14500    14500 14500   8500   14500   8500   8500   8500   8500   8500   8500       -
3

I think the change is much more likely to be in the way the table is generated than the actual codec speeds, but, in any case, I think it would require a code change, so you would have to report it on the bug tracker to get anything done.

If you have evidence for or against there being a real change in codec speeds, that would be important information for any bug report.

Note that the table is only used to determine relative costs.

4

I realise it’s all relative. However There’s a big difference between 1 and 9150 for ulaw to alaw, for example. I may also just downgrade to 1.8 and see if that helps. Nothing sounds too bad on regular speech as I can determine what codecs are used to connect but (a) that’s not scalable and (b) sound files in certain codecs are slowed down - a lot (like hand-turning an old reel-to-reel tape).

5

The sound file slow down may indicate a real problem, but has an easy workaround, simply store redundant versions in all the codecs used.

At one stage in the last year, I think there was a problem with conversions not taking the shortest path., so you should check the lastest version.

However, complaining here will do little, as these forums aren’t regularly monitored by developers.

6

Yeah that was my concern. I was using the latest LTS version (11.1.2) having just downloaded it but will monitor it and see how it goes. Thank you. Between posts, I’d already put up some 16bit 8000Hz encoded wav files which got around the problem for now but worried something ends up on a codec with a slow translation in the future. Still, I’m happy for now.