[asterisk-users] Use the NEW ulaw/alaw codecs (slower, but cleaner)

Matthew Fredrickson creslin at digium.com
Mon Nov 17 13:25:54 CST 2008


John Todd wrote:
> On Nov 11, 2008, at 3:44 PM, Steve Murphy wrote:
>> On Tue, 2008-11-11 at 16:11 -0700, 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.

Actually, with the way caching is done on nearly all modern processors, 
it is debatable whether or not a look up table is the optimal way to do 
the conversion, at least on such a simple codec such as ulaw or alaw. 
In fact, the amount of time it takes to fetch memory from a cache miss 
can easily ruin the single element lookup performance in a look up 
table.  And if you have large tables (such as in the linear to ulaw or 
alaw table), the tradeoff of having to service a cache miss versus a few 
cached instructions executing a native CPU clock speed makes it almost a 
no brainer (IMHO).

You'll pay a cache miss on the first time your run the routine, but the 
instructions running the routine will take up much less CPU cache space 
than the look up tables, increasing the likelihood of them being evicted 
(whereas the lookup table, taking up a lot more space, has a much better 
chance of causing a cache miss whenever you access).

Obviously, if you're running on a CPU with no cache, a look up table is 
a good way to do it.  I'm just saying that very few processors that are 
running Asterisk are running it on processors without processor caches.

Matthew Fredrickson
Digium, Inc.

>>>
>>> Wilton
>> Wilton--
>>
>> AFAIK, the current algorithms (old & new) are indeed table lookup.
>> It wouldn't hurt for you to do a code review on them, you might
>> be able to improve them...!
>>
>> murf
> 
> 
> 
> For those of you interested in a slightly longer discussion here,  
> there is discussion (Nov 14) on the voip-users-conference about this  
> and many other things:
> 
> http://www.talkshoe.com/talkshoe/web/talkCast.jsp?masterId=22622&cmd=tc
> 
> JT
> 
> ---
> John Todd
> jtodd at digium.com        +1-256-428-6083
> Asterisk Open Source Community Director
> 
> 
> 
> 
> 
> _______________________________________________
> -- 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




More information about the asterisk-users mailing list