>For those of you interested in a slightly longer discussion here, there is >discussion >(Nov 14)
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. 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. 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. 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. Wilton
_______________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
