[asterisk-bugs] [JIRA] (ASTERISK-23735) Transcoding makes bad choice in high-rate translations

[Alexander Traud (JIRA)]

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

Alexander Traud updated ASTERISK-23735:
---------------------------------------

    Attachment: gap_sample_rate.patch

The same happens for Ultra-Wide Band variant of Speex (aka speex32, speex-uwb, or speex/32000) and SiLK (aka silk24 or silk/24000). In the VoIP/SIP client [twinkle|http://twinkle.dolezel.info], speex-wb and speex-uwb are the only available wide-band codecs. The app [pjsua| http://www.pjsip.org/pjsua.htm] of PJProject allows to test speex32, silk24, and siren14.

*Steps to Reproduce*

# SIP channel driver _chan_sip_
# in the configuration file _sip.conf_ go for{code}
allow=!all,speex32{code}
# in the configuration file _extentions.conf_ go for{code}
exten => 600,1,Set(SIP_CODEC_INBOUND=speex32)
 same => n,Playback(demo-moreinfo)
 same => n,Goto(2){code}
# in twinkle, enable _speex-uwb_ via Menu → Edit → User profile → RTP audio → (Tab) Codecs → Active codecs → OK.
# in twinkle, dial _600_

*Expected Results*

Although Asterisk does not support 32 kHz, 24 kHz, 14 kHz, or 12 kHz natively, it should play at least the pre-recorded sound files of SLN16. Twinkle and pjsua should output wide-band audio.

*Actual Results*

Asterisk sends narrow-band audio.

*Notes*

In Asterisk on the Command-Line Interface (CLI), when I go for ‘core show channels’, I get
{code}
  NativeFormats: (speex32)
    WriteFormat: slin
     ReadFormat: speex32
 WriteTranscode: Yes (slin at 8000)->(slin at 32000)->(speex at 32000)
  ReadTranscode: No
{code}
My patch is technically the same as the already proposed patch. However, semantically, the issue is not about a format tuple but the whole transcoding path. In this case, it is at least a triple. Therefore, I did not touch the table which is just about tuples. Instead, I changed the code to find the best path, not only to go for the best score of each tuple, the shortest path, but also the difference/gap/distance between the sample rates – of the start (source) and ending point (destination) of the path.

The change was tested with speex32, silk24, and siren14. I did not test silk12, yet.

> Transcoding makes bad choice in high-rate translations
> ------------------------------------------------------
>
>                 Key: ASTERISK-23735
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-23735
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Codecs/General
>    Affects Versions: 12.2.0
>            Reporter: Richard Kenner
>         Attachments: gap_sample_rate.patch, trans.diff
>
>
> In main/translate.c, generate_table_costs considers any upsample equivalent if the slin in/out profile is the same. But that's wrong. The cost should be adjusted depending on how far apart the rate are. For example siren14 to slin32 should be via slin16, not slin. I modified that table to just add to the cost the difference in the rates and that fixes this problem, but I'm not sure enough of the scaling to know if that's the right amount to adjust it by.



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