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

[Asterisk Bug Tracker]

The following issue has been SUBMITTED. 
====================================================================== 
https://issues.asterisk.org/view.php?id=16841 
====================================================================== 
Reported By:                dvossel
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   16841
Category:                   Core/CodecInterface
Reproducibility:            random
Severity:                   minor
Priority:                   normal
Status:                     new
Asterisk Version:           SVN 
JIRA:                        
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-02-16 12:21 CST
====================================================================== 
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.


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

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-02-16 12:21 dvossel        New Issue                                    
2010-02-16 12:21 dvossel        Asterisk Version          => SVN             
2010-02-16 12:21 dvossel        Regression                => No              
2010-02-16 12:21 dvossel        SVN Branch (only for SVN checkouts, not tarball
releases) => N/A             
======================================================================