[asterisk-dev] [Code Review] Second attempt at choosing optimal translation paths, specifically when resampling signed linear formats.

[Mark Michelson]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/1772/
-----------------------------------------------------------

Review request for Asterisk Developers.


Summary
-------

This is a second attempt to fix ASTERISK-16821.

The first attempt can be found at https://reviewboard.asterisk.org/r/1715 . In that change, I went down the road of using the sample rate change as a means of determining the path to take. However, this opened the door for translation loops to occur when codec_resample was not loaded. This is because paths like slin->gsm->slin->g.722 might get chosen because the *overall* sample rate change would be the same as slin->g.722. Since the slin->gsm path was checked first, the slin->g.722 path was not seen as "better" since the sample rate change was the same.

This new fix expands on the first one by acting even more like Asterisk 10. This means we take into account both the sample rate change as well as the quality of the translation. This way, the former loop cannot happen because the quality of the translation is seen as much worse than the simple slin->g.722 translation.


This addresses bug ASTERISK-16821.
    https://issues.asterisk.org/jira/browse/ASTERISK-16821


Diffs
-----

  /branches/1.8/main/translate.c 356697 

Diff: https://reviewboard.asterisk.org/r/1772/diff


Testing
-------

Made sure that translations directly from slin->slin16 and slin16->slin are favored over those that have an intermediate step. Ensured that there were no loops in translation paths.


Thanks,

Mark

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20120224/50331f9c/attachment.htm>