[vorbis-dev] mdct.c

[Monty]

> As we're trying to put libvorbis on LEON chip running on XSV-800 FPGA
> board, the code runs now (simple player using Pthread on RTEMS/LEON)  but
> it seems that we have to implement some functions in hardware in order to
> help speed up the decoding process. We target this mdct_backward()
> first. Do you have any comment? Is there any other hardware-friendly and
> computation-intensive functions?

Most other operations are vectorizable...  The LSP filter code (only
used by re-pc bitstreams) could also benefit from
optimization/hardware implementation.  Aside from MDCT, there are no
other huge, expensive black-box transforms in decode.

> I am looking at the code from http://sourceforge.net/projects/ivdev/
> provided by Mr.Dan Conti and trying to make it "compilable" with gcc on
> Linux (if I have duplicating anyone's work please let me know :) ). As we
> have the limit that our FPU can run at only 25 MHz (which might not be
> fast enough to decode Ogg/Vorbis), we prefer to go with the no-fpu version
> so that we could run with higher frequency.

The ivdev code is useful, but there are important caveats to keep in
mind if you're going to put time into using it:

First and foremost, there's a few crash bugs in the ivdev code [to my
memory, one is in the bank switching ASM in
block.c:vorbis_synthesis_blockin(), code that has long since been
replaced in the reference encoder.  The other is in other ASM blocks
that make use of the condition code register; that register is not
marked as clobbered.  I'll freely admit that these two bugs are
actually my own fault ;-]

Secondly, the fixed-point conversion done in the code can't handle the
range necessary to deal with Vorbis 1.0 files; the range behavior
hardwired into the implementation was mostly sufficient for beta four,
but the codebooks and multiplication vectors for 1.0 simply can't fit
in 32 bits with a fixed point.  32.32 would work, as would a binary
point that could move within a 32 bit range (ARM cores can give this
to an only mildly clever implementation for free; this is the approach
I've taken).

So, in summary, the ivdev code is a fork of Vorbis from a long time
ago and doesn't reflect the stacks of bugfixes or complete 1.0 feature
set.  It does not work with any Ogg files produced by an Ogg encoder
from the past year or so, and it's my humble [but correct] opinion
that starting over with a fixed point port from current CVS is an
easier task than bringing ivdev up to date.

Monty

--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to 'vorbis-dev-request at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.