[Speex-dev] Speex split across processors?

[Paul Fagerburg]

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 at 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 at USherbrooke.ca>
> Université de Sherbrooke
> 
> 


-- 
"Oldcorps unbellyfeel doubleplusgood prolework."