Well, it's an ARM7TDMI core, so basically one register operation per
clock, with memory accesses taking longer. Having the memory on-chip
should make memory access much less of an impact.
I was afraid that you would answer the way you did: I thought about my
question after I sent it, and the "LP" in CELP is what makes it a
sequential process; it can't do linear prediction on a frame that the
other processor is encoding.
I'm looking at a specific set of parameters, probably 6kbps without
VAD. It doesn't have to sound great, just understandable. Being able
to recognize the person's voice on the other end is also a
requirement. Some of the very low bitrate codecs like 2.4kbps sound
more like a speech synthesizer than the actual speaker's voice; this
won't be acceptable.
I have some restrictions on the chip I'm able to use; I'd like to use
a single-chip micro instead of, e.g. a StrongARM with support logic
and external memory. I also believe that StrongARM is available
mostly (entirely?) in BGA packages, which are impossible to
hand-solder. I need hand-soldering, low cost, and low complexity.
I guess the only way to find out is to try it. I'll make some time to
build a klunky framework around the code so I can ship speech down a
serial port, encode it, and get back the encoded data and time to
encode. Assuming time to encode is less than time to playback, we've
got a winner.
-paul
On Apr 4, 2005 6:28 PM, Jean-Marc Valin <Jean-Marc.Valin@usherbrooke.ca>
wrote:> Hi,
>
> First, depending on how much your particular core gets done in one
> cycle, it is possible that Speex can encode in real-time on a 60 MHz
> (can't guaranty, of course). The main thing to watch here is the speed
> of the multiplier. As for parallel encoding, the first thing is that you
> can't just encode every other frame on each CPU. That's because of
the
> encoder memory. Also, most of the process is sequential. There are a few
> places where you could do stuff in parallel (for the same frame), but
> not that much. It would probably allow you to at least to real-time on a
> pair of 60 MHz (if it can't be done on only one) assuming decent
> communication between the two, but probably not much more. It would also
> require a lot of tweaking in the code, so I don't think it's worth
it
> (versus just getting a slightly faster chip).
>
> Jean-Marc
>
> Le lundi 04 avril 2005 ? 08:44 -0700, Paul Fagerburg a ?crit :
> > I am interested in using Speex in an embedded system built around an
> > ARM microcontroller. I have seen other posts indicating that Speex
> > can run in real-time on some iPAQ PDA's, but these are using a
> > StrongARM 166MHz processor. I'm looking more at the chips from
Atmel
> > (SAM7), Philips (LPC2xxx), and TI (TMS 470), which are ARM7TDMI with
> > on-chip SRAM and flash, running at speeds of 33 to 60MHz.
> >
> > 166 down to 60 is a big drop, but I'm hoping to gain performance
due
> > to lack of wait states (no external memory), and the lack of any O/S
> > running to eat cycles; the chip will only be encoding Speex.
> >
> > Still, it may not be enough. Is it possible to parallelize the
> > encoding, i.e. have two micros, each encoding every other frame? As
> > long as each micro could encode in 2x real-time or faster, the net
> > result would be a real-time encoding.
> >
> > I appreciate any help this group can provide.
> >
> > Thanks,
> >
> > -paul
> >
> >
> --
> Jean-Marc Valin <Jean-Marc.Valin@USherbrooke.ca>
> Universit? de Sherbrooke
>
>
--
"Oldcorps unbellyfeel doubleplusgood prolework."