<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.5730.11" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV>>For those of you interested in a slightly longer discussion here,
there is discussion </DIV>
<DIV>>(Nov 14)</DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>Thanks for the link. I just listened to the
segment. It sounded like the problem was going between linear and ulaw. As
has been previously mentioned, this may well be due to a broken algorithm that
has been widely published (as has the fix). It is absolutely inexcusable
for any errors to occurs simply going in and out of ulaw. ulaw is a lossy
compression, but the inverse function should always return a point near the
middle of the range that maps to a given ulaw number, such that barring
significant errors in the analog domain, a subsequent encoding would generate
the same ulaw value.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>Again, both ulaw and alaw (and their inverses)
should be simple table lookups, so getting the table right has absolutely
nothing to do with speed. Also, in response to some questions asked both
here and on the conference call, neither ulaw or alaw involve information
about more than one sample at a time, so there is absolutely no need of
buffering or anything else that would impact latency of the call. In a SIP
environment, it would probably be processed packet at a time, but the packet
size is determined entirely by other considerations, not the codec
algorithm.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>I'm not familiar with either the old or new code,
and there may be some general programming areas where code was cleaned up, and
the cleaner code was less efficient. However, there is absolutely no
reason, assuming a LUT implementation, that the transcoding fix should have any
impact on speed. The proper implementation is a single array element
lookup.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>Where a possible issue does exist (and it is
intractable) is going between ulaw and alaw. Both are lossy compression
yielding an 8 bit output, but using slightly different mapping. That means
that there cannot be a unique mapping from one to the other. For
some values a given ulaw number has more than one possible alaw equivalent
and for other values a given alaw number has more than one possible ulaw
equivalent. That means that each transcoding between alaw and ulaw (or
reverse) causes a slight loss of information. Best case scenario would be
that after two transcoding, standardized values are used such that no further
degradation occurs.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>Wilton</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV></BODY></HTML>