Displaying 8 results from an estimated 8 matches for "ip3k".
Did you mean:
ip32
2005 Feb 28
4
memory usage
...ould probably use). As for
> exc2, it can be removed, but I'm not sure if you can just use exc
> instead (maybe yes).
>
when removing "spx_sig_t *orig;" in the encoder, the stack usage
went from 17091 to 16451 bytes,
I have already got a working decoder running on my Ubicom IP3K,
using 10-15% of the CPU, with a decoder stack size of 4058 bytes.
The encoder is next..
/alfred
> Jean-Marc
>
--
Alfred E. Heggestad <alfredh@sxdesign.com>
SX Design
2005 Sep 04
2
[PATCH] fix gcc 3.4 warnings
hi
attached is a patch fixing some build warnings with ip3k-elf-gcc
(gcc 3.4-20030722-Ubicom-63-1211). not all fixes are elegant,
please review carefully before applying..
/alfred
-------------- next part --------------
A non-text attachment was scrubbed...
Name: warnings.diff
Type: text/x-patch
Size: 17666 bytes
Desc: not available
Url : http://lists.xi...
2005 Mar 10
1
Quick plug: Squeezebox2
--- Dan Sully <daniel@electricrain.com> wrote:
> Hi - just wanted to give a quick plug for my company's new product -
> Squeezebox2.
>
> We're doing native FLAC on the device now, in addition to
> visualizers, 802.11g and more.
this is cool, I added a status item on the FLAC site for it.
just as a data point for us, can you comment on the cpu that
is doing the FLAC
2005 Feb 28
2
memory usage
hi,
jean-marc: i think we can remove spx_sig_t *orig.
but am not sure about exc2Buf. is it for extension?
rgds,
tk
On Mon, 28 Feb 2005 12:42:38 -0500, Jean-Marc Valin
<Jean-Marc.Valin@usherbrooke.ca> wrote:
> Hi,
>
> I looked at the code I think there are still places where you can reduce
> memory. For example, I think bufSize can be reduced to around 400
> (instead of
2005 Mar 01
0
memory usage
...be removed, but I'm not sure if you can just use exc
>>instead (maybe yes).
>>
>>
>>
>when removing "spx_sig_t *orig;" in the encoder, the stack usage
>went from 17091 to 16451 bytes,
>
>I have already got a working decoder running on my Ubicom IP3K,
>using 10-15% of the CPU, with a decoder stack size of 4058 bytes.
>The encoder is next..
>
>
It will probably be very close, if you can do it.
I did a bunch of tests of encoder performance (on an Athlon XP 1700+) a
while back, and found that, for 8kbps CBR complexity 1, I got:
(...
2005 Mar 01
1
memory usage
...2000
now there is _almost_ enough RAM to allocate both encoder and decoder ;)
/alfred
> > when removing "spx_sig_t *orig;" in the encoder, the stack usage
> > went from 17091 to 16451 bytes,
> >
> > I have already got a working decoder running on my Ubicom IP3K,
> > using 10-15% of the CPU, with a decoder stack size of 4058 bytes.
> > The encoder is next..
> >
> >
> > /alfred
> >
> > > Jean-Marc
> > >
--
Alfred E. Heggestad <alfredh@sxdesign.com>
SX Design
2005 Sep 05
2
[PATCH] fix gcc 3.4 warnings
On Mon, 2005-09-05 at 10:29 +1000, Jean-Marc Valin wrote:
> > attached is a patch fixing some build warnings with ip3k-elf-gcc
> > (gcc 3.4-20030722-Ubicom-63-1211). not all fixes are elegant,
> > please review carefully before applying..
>
> Euh, could you explain what's wrong with "start" and "end"? Also, AFAIK,
> (int)floor(something) is valid, no?
>
there is no...
2005 Feb 19
2
memory usage
Hi
I am currently trying to port speex v1.1.6 to a microcontroller with
very limited memory (<64Kbyte RAM).
what I found when initialising the encoder, a chunk of 32Kb was
attempted to be alloced, which failed:
src/nb_celp.c:
void *nb_encoder_init(const SpeexMode *m)
{
/* snip */
st = (EncState*)speex_alloc(sizeof(EncState)+8000*sizeof(spx_sig_t));
/* snip */
}
same goes for the