[asterisk-dev] [Code Review] Don't take computational cost into account when creating multistep translations

[Kevin Fleming]

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

Ship it!


This looks sane to me. It would be unbelievably uncommon for someone to have two equal-length paths for the same translation that differ in cost, since none of the available codec modules for Asterisk have overlapping formats. For Asterisk 1.8, using the path length as the primary determining factor is a good plan.

- Kevin


On Feb. 6, 2012, 4:32 p.m., Mark Michelson wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1715/
> -----------------------------------------------------------
> 
> (Updated Feb. 6, 2012, 4:32 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> The linked issue mentions that Asterisk 1.8 will choose to translate from slin16 to slin8 via the G.722 codec rather than use codec_resample in order to translate directly between the formats. The reporter contends that the quality of the translation should be taken into effect in addition to the cost, suggesting that single-step translations should be favored over multi-step translations.
> 
> I did quite a bit of research, and I found that sometimes, Asterisk actually would translate from slin16 to slin8 directly, but most of the time, Asterisk would use G.722 as a middle step. And if I issued a "core show translation recalc 1000" so that translation costs were based off 1000 seconds of audio instead of 1, the cost clearly converged to the point that G.722 was the better path. Typically, the path from slin16->G.722->slin8 would have a total cost of around 1700, but the path directly from slin16->slin18 would have a cost of around 6500.
> 
> I also tested out Asterisk 10 to see how it chooses translation paths. Interestingly, Asterisk 10 does not use the combined computational cost to choose translation paths. Rather, it uses a separate cost scale based on the sampling rate change and the quality of the translation. So in this particular situation, since the slin16->g.722 is a lossy translation, but the slin16->slin8 is deemed a lossless translation, the slin16->slin8 translation will always be used.
> 
> SO, on to the actual change contained here. It's a two line change that simply takes computational cost out of the equation when creating multistep translations. This essentially means that a multistep translation will only be used if there is no direct translation between the source and destination formats.
> 
> I will concede that there may be a better way of addressing this issue, so if you have suggestions, please don't hesitate to let me know.
> 
> 
> This addresses bug ASTERISK-16821.
>     https://issues.asterisk.org/jira/browse/ASTERISK-16821
> 
> 
> Diffs
> -----
> 
>   /branches/1.8/main/translate.c 354120 
> 
> Diff: https://reviewboard.asterisk.org/r/1715/diff
> 
> 
> Testing
> -------
> 
> Started Asterisk, and recalculated translation matrix several times. After each, I issued "core show translation paths slin16" and ensured that the path chosen was always from slin16 directly to slin8 and never through g.722.
> 
> 
> Thanks,
> 
> Mark
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20120208/fe60b2db/attachment-0001.htm>