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

Asterisk Bug Tracker noreply at bugs.digium.com
Fri Oct 29 08:26:34 CDT 2010


The following issue has been set as RELATED TO issue 0018151. 
====================================================================== 
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-10-29 08:26 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.


======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0018151 SLIN/SLIN16 translation path is not opt...
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-10-29 08:26 lmadsen        Relationship added       related to 0018151  
======================================================================




More information about the asterisk-bugs mailing list