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
through
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 something very fast.
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 see the code, but
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
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 removed):
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
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. There are
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
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
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
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 amount of
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 amount of
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
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?
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
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 inverse
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
21 matches
Mail list logo
