[asterisk-dev] 0015504: [patch] G726 Codec has choppy audio on Version 1.6.1

Joshua Colp jcolp at digium.com
Tue Nov 10 15:12:49 CST 2009


----- "Dmitry Andrianov" <dimas at dataart.com> wrote:

> Guys,
> Im looking at the recently closed issue
> https://issues.asterisk.org/view.php?id=15504
> (the diff
> http://svnview.digium.com/svn/asterisk/branches/1.4/codecs/codec_g726.c?r1=229281&r2=229280&pathrev=229281
> )
> 
> Commit comment says:
> 
>    On some systems the translation core would actually consider
> g726aal2 -> g726 -> signed linear
>     to be a quicker path then g726aal2 -> signed linear which exposed
> this problem.
> 
> My understanding is that the only difference between these codecs is
> order of bytes (actually nibbles). So how this extra step in the
> transcoding chain can cause choppy sound? To me data decoded by any of
> these chains must match exactly. What am I missing?

There was a translator for going directly between the two G.726 types but
it was broken and did not do this correctly. I spent some time trying to make it
work but could not make it do so. Rather then spend more time on it I made the
decision to just completely remove it. In the real world there aren't very many
cases where it would actually get used.
 
> Another thought: is it a good idea in general to completely kill one
> of transcoders only because it gets used inefficiently? I agree that
> the long chain should be avoided but should it be done at the cost of
> killing one of transcoders? Arent there other ways?

It was removed because the actual code that did the translation was broken,
not because the path was getting chosen. If someone would like to try to fix
it they certainly can.

-- 
Joshua Colp
Digium, Inc. | Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at:  www.digium.com  & www.asterisk.org



More information about the asterisk-dev mailing list