[asterisk-bugs] [JIRA] (ASTERISK-29455) Local channels play back gsm files over ulaw files when both exist

[N A (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-29455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

N A updated ASTERISK-29455:
---------------------------

    Description: 
Strange issue with codec conversion that I noticed today. Despite the translation costs of slin192 <-> ulaw and slin192 <-> gsm being identical, an slin192 will pick a gsm audio file if both a gsm and ulaw candidate exist for a specific file. It plays ulaw files correctly if there isn't a candidate (same name) gsm file.

The correct behavior should be that ulaw is preferred over gsm, since the costs are identical, and ulaw is the higher quality codec, and being both uncompressed and raw audio, closer to slin format than gsm would be. Yet, it falls back to the lower quality codec for some reason which seems arbitrary.

An analysis of the ast_translator_build_path() function in channel.c along with DEBUG messages confirms the problem occurs here, and likely the actual bug lies with the ast_translator_best_choice function in translate.c.

It appears this function looks only at translation costs and the choice between two codecs can be arbitrary if costs are identical.

  was:
Strange issue with codec conversion that I noticed today. Despite the translation costs of slin192 <-> ulaw and slin192 <-> gsm being identical, an slin192 will pick a gsm audio file if both a gsm and ulaw candidate exist for a specific file. It plays ulaw files correctly if there isn't a candidate (same name) gsm file.

The correct behavior should be that ulaw is preferred over gsm, since the costs are identical, and ulaw is the higher quality codec, and being both uncompressed and raw audio, closer to slin format than gsm would be. Yet, it falls back to the lower quality codec for some reason which seems arbitrary.

An analysis of the ast_translator_build_path() function in channel.c along with DEBUG messages confirms the problem occurs here, and likely the actual bug lies with the ast_translator_best_choice function in translate.c.


> Local channels play back gsm files over ulaw files when both exist
> ------------------------------------------------------------------
>
>                 Key: ASTERISK-29455
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-29455
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Codecs/General
>    Affects Versions: 18.4.0
>            Reporter: N A
>
> Strange issue with codec conversion that I noticed today. Despite the translation costs of slin192 <-> ulaw and slin192 <-> gsm being identical, an slin192 will pick a gsm audio file if both a gsm and ulaw candidate exist for a specific file. It plays ulaw files correctly if there isn't a candidate (same name) gsm file.
> The correct behavior should be that ulaw is preferred over gsm, since the costs are identical, and ulaw is the higher quality codec, and being both uncompressed and raw audio, closer to slin format than gsm would be. Yet, it falls back to the lower quality codec for some reason which seems arbitrary.
> An analysis of the ast_translator_build_path() function in channel.c along with DEBUG messages confirms the problem occurs here, and likely the actual bug lies with the ast_translator_best_choice function in translate.c.
> It appears this function looks only at translation costs and the choice between two codecs can be arbitrary if costs are identical.



--
This message was sent by Atlassian JIRA
(v6.2#6252)