[CELT-dev] CELT grabbing 100KB of memory right off the top

[Timothy B. Terriberry]

> As for C99, please, think of those of us stuck with embedded toolchains. :)

Sorry, I live in perpetual hope. But that's why I also mentioned alloca.

> I had to go all over the code to remove the "restrict" keyword (I
> understand why you want it, but couldn't it be a macro--please?).  I

What's wrong with passing -Drestrict ? Anything can be a macro in C.

> That having been said.  After turning on all the compiler optimizations
> for speed, it seems that 28KHz, stereo, frame size of 120 bytes, bitrate

I assume you mean 120 samples.

> of 64kbps, and complexity 5 runs at about 50-60 MIPS on a PIC32 (MIPS
> R4K @ 80MHz).  My wall clock times show that it is encoding a 1 minute

50-60 MIPS sounds about the right ballpark for the encoder.

Right now, I'm pretty sure that all complexities of 5 or larger behave 
the same, so you're actually running at the maximum. For 120 sample 
frames, you could probably drop to 2 without losing much quality, though 
I don't expect it to make a huge speed difference (unless you enabled 
the pitch filter). Dropping to 1 disables short frames. Dropping to 0 
disables spreading. Both of those are probably bad ideas.

> stream in about 40-45 seconds.  My oscilloscope shows that my main loop
> is encoding a packet once every 3.4-3.5ms.
>
> This is, alas, too tight for my application (unless I can get another
> factor of 2 from somewhere--suggestions welcomed).  However, I may take
> another crack at it if I have time to cost engineer things a bit.

There are still probably plenty of things that can be done to make the 
encoder faster. It hasn't been a strong focus, because it's already an 
order of magnitude faster than encoders for similar quality high-latency 
codecs. Contributions welcome!