[Home]

Summary:ASTERISK-16821: SLIN/SLIN16 translation path is not optimal
Reporter:Andrew Lindh (andrew)Labels:
Date Opened:2010-10-17 20:28:45Date Closed:2012-03-01 18:28:19.000-0600
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Core/CodecInterface
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:Without libresample installed asterisk can not convert directly between SLIN and SLIN16, so it uses G.722 as the only path. It's bad, but better than nothing.

With libresample installed asterisk should use it to directly convert between SLIN and SLIN16 as that would be the path with the least loss. But, most of the time asterisk still uses G.722 to translate.

It would be best to include some version of libresample with asterisk 1.8 as there is now a common need for SLIN/SLIN16 conversion.

I don't know if the "cost" is calculated wrong or if there is a need to pick the best path, even at a higher cost, to reduce loss.

Related to bugs ASTERISK-1661841 ASTERISK-1768934


****** ADDITIONAL INFORMATION ******

With libresample installed (some output removed):

>core show translation paths slin16
--- Translation paths SRC Codec "slin16" sample rate 16000 ---
       slin16     To slin      : slin16->g722->slin
       slin16     To speex16   : slin16->speex16
       slin16     To g722      : slin16->g722

>core show translation paths slin
--- Translation paths SRC Codec "slin" sample rate 8000 ---
       slin       To speex     : slin->speex
       slin       To speex16   : slin->slin16->speex16
       slin       To g722      : slin->g722
       slin       To slin16    : slin->slin16


Here is part of the translation times:
>core show translation
          slin  g722   slin16
  slin    -     4000   4000
  g722    1     -       1
slin16    2     1       -

Comments:By: Andrew Lindh (andrew) 2010-10-18 13:00:33

From the show translation, slin16->g722->slin costs = 2, and slin16->slin = 2.  There are 2 translations using G.722 and only 1 with libresample, but the time costs are the same. One simple fix would be to add 1 (or more) to every intermediate translation as a path cost.

Faster or slower CPUs may show a different result than my system (Pentium 4-530 3Ghz no HT).

By: Leif Madsen (lmadsen) 2010-10-29 08:31:09

The translation is also done programmaticly so perhaps there isn't a real different cost associated with the translations path?

However I'm going to acknowledge this issue and have someone who is better learned about this to comment.

By: Mark Michelson (mmichelson) 2012-02-17 10:16:19.456-0600

Reopening issue. The fix I put in caused a bad regression so this needs to be looked at more.