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

[Dmitry Andrianov]

Joshua,
Just to be clear - I do not have equipment with g726 so my thoughts are based only on what I see in the code.

I clearly see your point and I agree. However just from looking at the code I do not understand how is it possible that two different paths produce different result.

The only difference between g726tolin_framein and g726aal2tolin_framein is the order in which they process nibbles. And the only thing g726tog726aal2_framein does is changing order of these nibbles. So in theory g726tog726aal2_framein + g726aal2tolin_framein should be indistinguishable from g726tolin_framein. If it is not true, it can indicate a problem with the whole transcoding core not just with this particular codec. This is why I believe it is good idea to investigate.

I would really love to help but I do not have any equipment using these codecs.

The only thing in the code which concerns me is the samples/datalen math. I do not quite understand it because g726tog726aal2_framein does 

        pvt->samples += f->samples;
        pvt->datalen += f->samples; /* 1 byte/sample */

however if I understand how codec works properly, it uses 4-bits per sample so samples != datalen and it should be

        pvt->samples += f->samples;
        pvt->datalen += f->datalen;

Can't check it though :(

Regards,
Dmitry Andrianov

-----Original Message-----
From: asterisk-dev-bounces at lists.digium.com [mailto:asterisk-dev-bounces at lists.digium.com] On Behalf Of Joshua Colp
Sent: Wednesday, November 11, 2009 12:13 AM
To: Asterisk Developers Mailing List
Subject: Re: [asterisk-dev] 0015504: [patch] G726 Codec has choppy audio on Version 1.6.1

----- "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

_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev