[asterisk-bugs] [Asterisk 0008126]: [patch] G.711 codec woes

[noreply at bugs.digium.com]

The following issue has been REOPENED. 
====================================================================== 
http://bugs.digium.com/view.php?id=8126 
====================================================================== 
Reported By:                fossil
Assigned To:                murf
====================================================================== 
Project:                    Asterisk
Issue ID:                   8126
Category:                   Core/CodecInterface
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     feedback
Asterisk Version:            SVN 
SVN Branch (only for SVN checkouts, not tarball releases):  1.2 
SVN Revision (number only!): 44743 
Disclaimer on File?:        Yes 
Request Review:              
====================================================================== 
Date Submitted:             10-09-2006 20:21 CDT
Last Modified:              08-20-2007 19:05 CDT
====================================================================== 
Summary:                    [patch] G.711 codec woes
Description: 
There is a *number* of problems in the a-law and u-law core transcoders
(most severe first):

1. a-Law decoder does not add the rounding error to the linear samples
output;
This results in a stable amplitude drop in the decoded signal overall, but
the negative phase portion of the signal is even more adversely affected:
the amplitude drop actually accumulates with consequtive transcodings (see
attached test patch). If the call encounters 127 tandem a-law transcodings
(a-alaw -> slin -> a-law -> slin -> ...), the entire negative portion will
be reduced to http://bugs.digium.com/view.php?id=#0.

2. Lookup table-driven slin->law coding rounds the negative values the
wrong way;
The breaks in linear value sequences do not happen where the table-driven
slin->law system expect them to. This results in certain negative linear
values to be encoded incorrectly (see attached test patch), which isn't
such a *big* problem, but a problem nonetheless.
There is no one-liner fix for this issue. To fix this, for example, we
could generate only half the slin->law table, for positive values only.
This table would contain half-cooked law bytes, so that the sign could be
added later to the values, along with the post-coding transform (NOT for
u-law and XOR 0x55 for a-law). In this case, AST_LIN2MU() would look
something like this:

inline unsigned char AST_LIN2MU(short sample)
{
  unsigned sign = ((unsigned)sample & 0x8000) >> 8;
  unsigned char law = __ast_lin2mu[(sample & 0x7fff) >> 2];
  return ~(law | sign);
}

3. slin->a-law and slin->u-law functions handle value -32768 incorrectly;
This is not really a problem when using a lookup table system because the
slot of -32768 is overwritten later, but for the sake of correctness...

4. alaw.c:linear2alaw() is less than optimal;

5. slin->law lookup table generation code is less than optimal;
There is no reason to enumerate all the possible values between -32768 and
32767 when most of the results are overwritten later.

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

---------------------------------------------------------------------- 
 fossil - 08-20-07 19:05  
---------------------------------------------------------------------- 
Reopening only to add a note.

The tandem transcoding degradation is only present in a-law -- issue (1).
The other issues are independent of this. Issue (1) is fixed by a trivial
one-liner patch -- g711-minimum.patch. This patch cannot possibly make
anything worse, only better, just to let you know. It may even deserve a
bug of its own.

Now to the effects: audibility is highly subjective, but I think the
distortion would be audible to an average user after 4-6 tandem
transcodings (alaw -> slin -> alaw), depending on the original signal
quality. Recall that the coding is logarithmic -- mantissa + exponent, and
the problem is such that during decoding the a-law byte is effectively
reduced by 1 every time. This means that the amplitude of signal's negative
portion is halved every 8 tandem transcodings. That is a pretty nasty
entropy ;-).
Also, in my experience, depending on the strength of the original signal,
just 2 tandem transcodings can prohibit faxing over a-law -- the
accumulated distortion creates harmonics that screw up DSPs.
My 2 cents. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
08-20-07 19:05  fossil         Note Added: 0069128                          
======================================================================