"show translation" ok with 1.4.x but 1.6.1.x is ba

Hi,

i just built com 1.6.x Installations to get ready and test for my dialplan changes (because of deprecated things in 1.6.x).
But whatever i do, I cant get any good results with "core show translation"
There are lots of entries with 3000, 4999 an even 14998!! (see code quotes below). It does not make a difference if I use 32bit or 64bit OS. And if I compile and use 1.4.x on the otherwise unaltered machine/OS it is OK with table entries of 1, and 2 (which is order of magnitues better than in 1.6.x).
I even tried to set compiler option ‘don’t optimize’, as pointed out elswhere, but this didn’t make a difference.

BTW: OS is CentOS 5.3 (x32 and x64 - both tested each on two different Machines, problem persists)

Here is sample console output of 1.4.26.1[code]

Connected to Asterisk 1.4.26.1 currently running on astdemo32 (pid = 2284)
Verbosity was 3 and is now 5
astdemo32*CLI> core show translation
Translation times between formats (in milliseconds) for one second of data
Source Format (Rows) Destination Format (Columns)

      g723 gsm ulaw alaw g726aal2 adpcm slin lpc10 g729 speex ilbc g726 g722
 g723    -   -    -    -        -     -    -     -    -     -    -    -    -
  gsm    -   -    2    2        2     2    1     2    -    10    8    2    -
 ulaw    -   2    -    1        2     2    1     2    -    10    8    2    -
 alaw    -   2    1    -        2     2    1     2    -    10    8    2    -

g726aal2 - 2 2 2 - 2 1 2 - 10 8 1 -
adpcm - 2 2 2 2 - 1 2 - 10 8 2 -
slin - 1 1 1 1 1 - 1 - 9 7 1 -
lpc10 - 2 2 2 2 2 1 - - 10 8 2 -
g729 - - - - - - - - - - - - -
speex - 2 2 2 2 2 1 2 - - 8 2 -
ilbc - 2 2 2 2 2 1 2 - 10 - 2 -
g726 - 2 2 2 1 2 1 2 - 10 8 - -
g722 - - - - - - - - - - - - -[/code]

And this is from same machine/OS (nothing altered, only compiled/installed 1.6 instead of 1.4).

[code]Connected to Asterisk 1.6.1.4 currently running on astdemo32 (pid = 7546)
Verbosity was 3 and is now 4
– Remote UNIX connection
astdemo32*CLI> core show translation
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 slin16
 g723     -     -     -     -        -     -     -     -     -     -     -     -     -      -
  gsm     -     -     2     2     1001     2     1  3000     - 10999 16998  1001  1001   1001
 ulaw     -  3000     -     1     1001     2     1  3000     - 10999 16998  1001  1001   1001
 alaw     -  3000     1     -     1001     2     1  3000     - 10999 16998  1001  1001   1001

g726aal2 - 3001 3 3 - 3 2 3001 - 11000 16999 1 1002 1002
adpcm - 3000 2 2 1001 - 1 3000 - 10999 16998 1001 1001 1001
slin - 2999 1 1 1000 1 - 2999 - 10998 16997 1000 1000 1000
lpc10 - 4999 2001 2001 3000 2001 2000 - - 12998 18997 3000 3000 3000
g729 - - - - - - - - - - - - - -
speex - 4999 2001 2001 3000 2001 2000 4999 - - 18997 3000 3000 3000
ilbc - 5998 3000 3000 3999 3000 2999 5998 - 13997 - 3999 3999 3999
g726 - 3000 2 2 1 2 1 3000 - 10999 16998 - 1001 1001
g722 - 4999 2001 2001 3000 2001 2000 4999 - 12998 18997 3000 - 999
slin16 - 6999 4001 4001 5000 4001 4000 6999 - 14998 20997 5000 2000 -[/code]

Please advice on what to check to get it back to good results as in 1.4.

Any help is greatly appreciated.
Pleas let me know, if (and what) information you need in addition to takle this down.

Regards
thomas[/code]

note that 1.4 shows times in MILLIseconds, and in 1.6 they’re shown as MICROseconds. 1 millisecond = 1000 microseconds.

Aaaaah - I see! - seems to be a RTFM issue =;-)
Thank you so much for pointing this out.
I really feared there was something ‘wrong’ in the background, even if my installation didn’t ‘suffer’ from bad transcoding.
This issue hindered me - because of the bad ‘feeling’ - to step forward to production.
Again many thanks for answering (especially because answering to this ‘older’ post) - it really helped me.
Thomas

thirsch: so you feel better… just got the same “issue”… thanks for asking before me!