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

Thu Aug 12 15:17:16 CDT 2010

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:                     closed
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:              
Resolution:                 fixed
Fixed in Version:           
====================================================================== 
Date Submitted:             2010-02-16 12:21 CST
Last Modified:              2010-08-12 15:17 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.

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

---------------------------------------------------------------------- 
 (0125924) svnbot (reporter) - 2010-08-12 15:17
 https://issues.asterisk.org/view.php?id=16841#c125924 
---------------------------------------------------------------------- 
Repository: asterisk
Revision: 282048

_U  trunk/
U   trunk/CHANGES
U   trunk/include/asterisk/translate.h
U   trunk/main/cli.c
U   trunk/main/translate.c

------------------------------------------------------------------------
r282048 | dvossel | 2010-08-12 15:17:16 -0500 (Thu, 12 Aug 2010) | 42
lines

Merged revisions 282047 via svnmerge from 
https://origsvn.digium.com/svn/asterisk/branches/1.8

........
  r282047 | dvossel | 2010-08-12 15:15:41 -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=282048 

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