[asterisk-bugs] [Asterisk 0016841]: Codec translation path builder does not produce expected results with 16khz and 32khz audio

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=16841 
====================================================================== 
Reported By:                dvossel
Assigned To:                dvossel
====================================================================== 
Project:                    Asterisk
Issue ID:                   16841
Category:                   Core/CodecInterface
Reproducibility:            random
Severity:                   minor
Priority:                   normal
Status:                     acknowledged
Target Version:             1.6.2.12
Asterisk Version:           SVN 
JIRA:                       SWP-931 
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2010-02-16 12:21 CST
Last Modified:              2010-08-12 15:15 CDT
====================================================================== 
Summary:                    Codec translation path builder does not produce
expected results with 16khz and 32khz audio
Description: 
The codec translation path builder only has the ability to distinguish what
path has the least translation cost involved, but when dealing with sample
rates greater 16khz the path builder should also consider the quality of
the translation.

For example. I have seen issues where a translation path between a 16khz
codec and another 16khz codec will result in a translation path containing
8khz slin.  While converting down to 8khz slin may have the least cost, it
reduces quality.

I am proposing that the translation path builder not consider a path
containing a conversion sample rate less that the lowest sample rate
involved in the call, unless there is no other way of going about it.  So
if one side of the call is 16khz and the other side is a different 16khz
codec, the goal should be to have every translation that takes place in
that path be 16khz if possible regardless of cost.

We also need a way to view the translation path being used by a call. 
This should probably be shown during the 'core show channel' output.   If
this output is considered a new feature, I recommend making it at least
available for debug builds in existing branches.

Changes Required
- The translation path builder must take into account the sampling rate
used.
- A channel's translation path must be viewable
- A unit test verifying the translation path builder works as expected.


====================================================================== 

---------------------------------------------------------------------- 
 (0125923) svnbot (reporter) - 2010-08-12 15:15
 https://issues.asterisk.org/view.php?id=16841#c125923 
---------------------------------------------------------------------- 
Repository: asterisk
Revision: 282047

U   branches/1.8/CHANGES
U   branches/1.8/include/asterisk/translate.h
U   branches/1.8/main/cli.c
U   branches/1.8/main/translate.c

------------------------------------------------------------------------
r282047 | dvossel | 2010-08-12 15:15:40 -0500 (Thu, 12 Aug 2010) | 35
lines

improved translation paths for wideband codecs

The problem I'm addressing is that Asterisk's current
method of building the least cost translation paths
between codecs does not take into account sample rate.
For instance, it was possible for siren14 (a 32khz codec),
to contain the a translation path to siren7 (a 16khz
audio codec) that goes through slin at 8khz.  In this
case Asterisk takes a 32khz codec, down samples it to
8khz and then up samples it to 16khz which is terrible
regardless if it is computationally less expensive.  This
patch now builds translation paths that give priority to
maintaining the best possible sample rate before taking
into consideration computational cost.  This patch also
adds cli commands to expose what translation paths are
actually being used.

Changes:
1. Translation paths will never contain a step that changes
the sample rate unless absolutely necessary.
2. When choosing the best codec to make two channels compatible.
Shared codecs with the highest sample rate are given priority.
3. A new cli command to show all translation paths available
for a specific codec 'core show translation paths [codec name]'
has been added.
4. 'core show translation' which displays the translation
matrix now includes the new higher bit audio codecs in the table.
5. 'core show channel [channel name]'  now displays the
translation paths if translation is used.

(closes issue https://issues.asterisk.org/view.php?id=16841)
Reported by: dvossel

Review: https://reviewboard.asterisk.org/r/842/

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=282047 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-08-12 15:15 svnbot         Checkin                                      
2010-08-12 15:15 svnbot         Note Added: 0125923                          
======================================================================