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
On Tue, Nov 11, 2008 at 4:19 PM, Karl Fife <[EMAIL PROTECTED]> 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 al
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 late
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
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
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 invers
>It wouldn't hurt for you to do a code review on them,
I'd better get more up to speed on * in general first. It would be interesting
to compare them to my code. However, I don't have a useful * installation
here, yet--I'm working on it.
Wilton
__
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 t
>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
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
Matthew Fredrickson <[EMAIL PROTECTED]> writes:
> 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 ti
Benny Amorsen wrote:
> Matthew Fredrickson <[EMAIL PROTECTED]> writes:
>
>> 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.
That's a good observation I hadn't considered. No, none of the CPUs I work
with cache anything other than the next few instructions. But, like
Matthew Fredrickson wrote:
> 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 m
Steve Underwood wrote:
> Matthew Fredrickson wrote:
>> 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 amoun
Steve Underwood wrote:
> Matthew Fredrickson wrote:
>> 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 amoun
Steve Underwood <[EMAIL PROTECTED]> writes:
> In spandsp I do the G.711 conversions algorithmically. Most modern
> processors have a "where is the top 1" instruction, and that reduces the
> calculations to something very fast.
Very nice! I'd like to see the code, but I'm too lazy to go look
thr
In article <[EMAIL PROTECTED]>,
Benny Amorsen <[EMAIL PROTECTED]> wrote:
> Steve Underwood <[EMAIL PROTECTED]> writes:
>
> > In spandsp I do the G.711 conversions algorithmically. Most modern
> > processors have a "where is the top 1" instruction, and that reduces the
> > calculations to somethi
Benny Amorsen wrote:
> Steve Underwood <[EMAIL PROTECTED]> writes:
>
>
>> In spandsp I do the G.711 conversions algorithmically. Most modern
>> processors have a "where is the top 1" instruction, and that reduces the
>> calculations to something very fast.
>>
>
> Very nice! I'd like to se
Interestingly the Linux kernel has this for find-last-set:
static inline unsigned long __fls(unsigned long word)
{
asm("bsr %1,%0"
:"=r" (word)
:"rm" (word));
return word;
}
spandsp has this (Everything non-x86 has been removed):
static __inline__ int top_bit(
Benny Amorsen wrote:
> Interestingly the Linux kernel has this for find-last-set:
>
> static inline unsigned long __fls(unsigned long word)
> {
>asm("bsr %1,%0"
>:"=r" (word)
>:"rm" (word));
>return word;
> }
>
> spandsp has this (Everything non-x86 has been
21 matches
Mail list logo