Summary:ASTERISK-23735: Transcoding makes bad choice in high-rate translations
Reporter:Richard Kenner (kenner)Labels:patch pjsip
Date Opened:2014-05-12 18:18:04Date Closed:2017-11-30 09:31:53.000-0600
Versions:12.2.0 Frequency of
causesASTERISK-27549 [patch] translate: Avoid absolute value on unsigned substraction.
Environment:Attachments:( 0) gap_sample_rate.patch
( 1) trans.diff
Description: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.
Comments:By: Rusty Newton (rnewton) 2014-05-20 09:57:38.278-0500

Richard would you want to attach your patch under license so that other developers can check it out?

[Code Review process|https://wiki.asterisk.org/wiki/display/AST/Code+Review]

By: Richard Kenner (kenner) 2014-05-20 10:30:02.762-0500

As I said, I don't think this patch is completely correct, but suggests the type of fix required.

By: Rusty Newton (rnewton) 2014-05-20 10:33:07.984-0500

That is fine. If you post it on Reviewboard as mentioned in the code review process, others can work with you to help identify the best fix.

By: Alexander Traud (traud) 2017-11-26 11:53:36.965-0600

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}
# 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.


In Asterisk on the Command-Line Interface (CLI), when I go for ‘core show channels’, I get
 NativeFormats: (speex32)
   WriteFormat: slin
    ReadFormat: speex32
WriteTranscode: Yes (slin@8000)->(slin@32000)->(speex@32000)
 ReadTranscode: No
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.

By: Friendly Automation (friendly-automation) 2017-11-30 09:31:55.272-0600

Change 7373 merged by Jenkins2:
translate: Transcode siren14, speex32, silk24, and silk12 via slin16.


By: Friendly Automation (friendly-automation) 2017-11-30 10:07:22.927-0600

Change 7372 merged by Jenkins2:
translate: Transcode siren14, speex32, silk24, and silk12 via slin16.


By: Friendly Automation (friendly-automation) 2017-11-30 10:17:15.285-0600

Change 7371 merged by Jenkins2:
translate: Transcode siren14, speex32, silk24, and silk12 via slin16.