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

[noreply at bugs.digium.com]

The following issue has been CLOSED 
====================================================================== 
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:                     closed
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:              
Resolution:                 open
Fixed in Version:           
====================================================================== 
Date Submitted:             10-09-2006 20:21 CDT
Last Modified:              08-20-2007 17:45 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.

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

---------------------------------------------------------------------- 
 murf - 08-20-07 17:45  
---------------------------------------------------------------------- 
Fossil--

I'm closing this bug for now. Please, feel free, if it's not too much
trouble for you, to add a note to this bug, and tell us what your estimate
of the number of times sound would be passed thru the 'old' (current)
ulaw/alaw codecs before an average human would be able to detect the
degradation. If it's low enough, we'll port your changes to 1.4.

Many thanks for your hard work! I'm going to make sure you get some karma
for this! 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
08-20-07 17:45  murf           Status                   ready for testing =>
closed
08-20-07 17:45  murf           Note Added: 0069126                          
======================================================================