[Speex-dev] Would be nice to conditionally compile out coding modes and code tables...

Miles, Stewart
2006-12-14T10:10:54Z

> -----Original Message-----
> From: Jean-Marc Valin [mailto:jean-marc.valin@usherbrooke.ca]
> Sent: Thursday, December 14, 2006 2:51 AM
> To: Miles, Stewart
> Cc: speex-dev@xiph.org
> Subject: Re: [Speex-dev] Would be nice to conditionally
> compile out coding modes and code tables...
>
> Miles, Stewart a ?crit :
> > I'm only using the narrow-band encoder on my embedded
> system and have
> > removed all references to the wide-band and ultra-wide band encoder
> > functions and tables. They will be pulled in by the linker
> due to the
> > references made by the structures in modes.c.  Attached is a
> > replacement modes.c for compiling out modes that are not in use for
> > anyone who's interested.
>
> There's already a --disable-wideband (and corresponding
> DISABLE_WIDEBAND) option in the code, so I'm not sure what
> your patch is supposed to add.

Searching the code (speex 1.0.5) I don't find DISABLE_WIDEBAND.  This is new
to speex 1.2 and I wasn't aware of the update.

> Also, disabling narrowband
> doesn't make sense because it's used by the wideband code.

After reading the code again, you're absolutely right (of course) each
progressively more complex codec references the previous one.  So disabling
narrow-band doesn't make sense.

>
> > Also, I've removed the dynamic memory allocation of the encoder
and
> > decoder.  To do this I had to determine the required size of the
> > encoder and decoder states since i'm working on a fixed
> memory platform I simply
> > handle the worst case, see the attached statesize.h.   Now
> I can do this
> > sort of thing...
> >
> > MyDecoderClass decoders[5];
> >
> > .. will means all of my decoder states are contiguous and
> quick to DMA.
> > It also improves cache consistency when the input buffers
> are placed
> > in MyDecoderClass.
>
> There's actually a much simpler way of making everything
> contiguous. All you need to do is allocate (or reserve or
> whatever) a big block yourself and override speex_alloc() and
> speex_free() (and speex_alloc_scratch if you don't have a C99
> compiler) to distribute that memory explicitly.

I completely understand that it's possible to override speex_alloc() and
speex_free(), in fact that's what i've done.  However, how much memory
do I reserve?  Without running the code I would like it to be possible to
reserve the appropriate memory for my required codecs.  Running the code to
determine the magic memory size to reserve is not very user-friendly and not
very good if future revisions of the library are released as the old code with
the magic allocation size will fail.  Determining whether an allocation is
possible at compile time is far more preferable than at run-time.

Which leads me to another point of irritation.  I noticed that you stated that
people shouldn't be using MAX_BYTES_PER_FRAME to reserve space for the
output of the encoder and that it's far better to just allow speex_bits to
realloc it's out of space
http://lists.xiph.org/pipermail/speex-dev/2003-August/000515.html .  For a lot
of embedded systems it's very important to know ahead of time how much
memory is required for an operation.  In fact the memory required should be
known at compile time so that the application will always function correctly.
At the very least, the worst case scenario should be accounted for so the
application never fails due to being out of memory.  So something like
MAX_BYTES_PER_FRAME is a pretty good idea since it allows application developers
to prepare for the worst case.  What would be nice, would be a
MAX_BYTES_PER_FRAME type constant that defines the maximum packet size per
encoder mode.  How did MAX_BYTES_PER_FRAME end up at the magic number of 2000
bytes?  A frame of 2000 bytes is 1000 uncompressed mono 16-bit PCM samples.

>
> > Would be nice for functionality like this to make it into the main
> > line of code.
>
> Anything that you need that isn't covered by the explanations above?
>
> 	Jean-Marc
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit
> http://www.messagelabs.com/email
> ______________________________________________________________________
>

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________