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

In Asterisk 1.6, there is an option to use the 'new g.711 algorithm'.  
"Use the NEW ulaw/alaw codec's (slower, but cleaner)"

By slower does this mean more 'expensive', or does it instead mean that
there will be more algorithmic latency?  Both?  Can anyone speak to the relative
increases?

With regard to accuracy, can anyone speak to what kind of situation might
demonstrate the benefit of the new algorithm?  i.e. transcoding, SpanDSP, Analog
interfaces (DAHDI) etc.

Thanks
Karl
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.digium.com/pipermail/asterisk-users/attachments/20081111/36a56619/attachment.htm

On Tue, Nov 11, 2008 at 4:19 PM, Karl Fife <karlfife at gmail.com> wrote:
>  In Asterisk 1.6, there is an option to use the 'new g.711
algorithm'.
> "Use the NEW ulaw/alaw codec's (slower, but cleaner)"
>
> By slower does this mean more 'expensive', or does it instead mean
that
> there will be more algorithmic latency?  Both?  Can anyone speak to the
> relative increases?
>
> With regard to accuracy, can anyone speak to what kind of situation might
> demonstrate the benefit of the new algorithm?  i.e. transcoding, SpanDSP,
> Analog interfaces (DAHDI) etc.
>
> Thanks
> Karl
>
>
>
Interesting....

Alaw and Ulaw algorithms slower and cleaner?  Slower would imply problems
with FAX or whatever.

Not sure how uncompressed audio could be cleaner and why on earth one would
want it slower?

What's next?  The new, improved, under new management, SLIN?

PS, I am sure (75% anyways) that this new algorithm is good for
something.....

-- 
Thanks,
Steve Totaro
+18887771888 (Toll Free)
+12409381212 (Cell)
+12024369784 (Skype)
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.digium.com/pipermail/asterisk-users/attachments/20081111/f6eb85ca/attachment.htm

On Tue, 2008-11-11 at 15:19 -0600, Karl Fife wrote:
> In Asterisk 1.6, there is an option to use the 'new g.711
> algorithm'.  
> "Use the NEW ulaw/alaw codec's (slower, but cleaner)"
>  
> By slower does this mean more 'expensive', or does it instead mean
> that there will be more algorithmic latency?  Both?  Can anyone speak
> to the relative increases?
>  
> With regard to accuracy, can anyone speak to what kind of situation
> might demonstrate the benefit of the new algorithm?  i.e. transcoding,
> SpanDSP, Analog interfaces (DAHDI) etc.
>  
> Thanks
> Karl
Karl--

I was involved in merging those patches into Asterisk. They are slightly
slower than the original u/a-law algorithms, but not much slower. The
u/a-law code are the fastest codecs Asterisk has. As Kevin once said,
"1.4 x of 0 is still zero". The author of the fixes told me that his
fixes straighten out problems with coding vs. decoding that were in
the original code. In the original code, he said, after 4 or so hops,
fax transmissions would no longer work.

Hope this helps.

murf


-- 
Steve Murphy
Software Developer
Digium
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3227 bytes
Desc: not available
Url :
http://lists.digium.com/pipermail/asterisk-users/attachments/20081111/dc2c0d43/attachment.bin

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.

Wilton
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.digium.com/pipermail/asterisk-users/attachments/20081111/02b83977/attachment.htm