Wilton Helm wrote: > I'm a bit puzzled, also, having implemented ulaw and alaw in an > embedded application. Each can be done with a 16 Kbyte table in about > 0 time with no errors. There are probably tricks that will cut the > table down by 2 or 4 X for a small cost in CPU cycles. The inverse > requires 256 16 bit words. I thought ulaw and alaw were pretty much > no brainers. I don't know of any gottchas. Why anyone with more that > a few K bytes of total system memory would even consider anything > other than a lookup table is beyond me. Lookup tables occupy cache, though with the latest CPUs getting 12M of cache a couple of 16k byte tables may not be an issue. When the cache was 256k it was.
What is puzzling here is why the new code should be slower. Asterisk has always implemented these codecs incorrectly. In fact, a lot of projects did. They all used the same broken 1 page implementation from Sun :-). Most projects sorted this out some time ago, but the Asterisk people didn't seem to care. Even with a single transcoding the Sun A-law code sounds bad on quiet voices. Nobody else saw a speed drop when they changed. In fact, the only way to do a-law <-> u-law correctly is with a 256 byte lookup tables, so that *has* to be fast. Steve _______________________________________________ -- 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
