[CELT-dev] CELT grabbing 100KB of memory right off the top
Timothy B. Terriberry
tterribe at xiph.org
Mon Apr 18 15:32:58 PDT 2011
> 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!
More information about the celt-dev