Vorbis dev - Mar 2003 - Implementation of vorbis using only the documentation

Reinventing the wheel is fun. I've just got working a (sort of) complete
implementation of vorbis using (very nearly) only the documentation.
This was quite easy overall as the documentation is very comprehensive
and clear. Nice job, whoever put it together!

The one spot I had some trouble with was the low level residue decode.
The pseudo code at
http://www.xiph.org/ogg/vorbis/doc/vorbis-spec-res.html for the packet
decode has a few bugs/typos in it and I couldn't get it working. In the
end I resorted to looking at vorbis/lib/res0.c and working out what that
did (nice for-loop variables i, j, k and l whoever wrote that!) Shame
really - I wanted to completely "clean room" it.

This is all just a bit of fun for my personal amusement, but it struck
me that there are issues with getting Vorbis to work efficiently on
portables using ARM or dsp based processors. I know that Tremor works,
but it does evil things like dynamic memory allocation during normal
playback, and I'm thinking it would be great to have all the allocation
at setup time, with a known upper bound - or even a single allocation at
player startup. In summary:

1) The documentation intro says all files have a rule of thumb of 4KB
setup headers max. The smallest a worst-case codebook would be in memory
is therefore roughly 4KB, but in practice would be much larger.

2) The window size maximum of 8192 points is a problem. Given a maximum
of 2 channels and 16 bit intermediate values (with block floating point,
but still sucks for accuracy) that would require 32KB of intermediate
storage. You'd still need to do in-place dot products of floor * residue
on the fly or you need twice as much.

3) Window shapes need to be somewhat precalculated. Size depends on how
much you mind approximation and playing tricks with table lookups. For
an 8192 point window, I'd say 8KB is a reasonable ball park figure.

That's already about 44KB. Given a processor like a Cirrus 7312 (very
common), which has 48KB of internal SRAM, you'd be hard pressed to fit
everything given a worst case in-spec file. It would spill to SDRAM and
you'd suffer a large performance hit all of a sudden. That's assuming
your processor even has SDRAM. Most of my worst case figures disappear
if you limit window size to 2048. Admittedly, I haven't tried
implementing my program with any thought to memory size yet - so this is
all guesswork.

Anyway, I'm sure you're very aware of these issues at Xiph. I think a
very specific "portable profile" would be a good thing to document.
Defining the upper bounds of headers and window sizes etc would make it
easier for someone to say "my codec will definitely play any
portable-profile vorbis file", rather than "my codec will play any
reasonable vorbis file". The latter behaviour would lead to rather bad
user experiences.

I'll be tidying the code a bit (s/assert(false)/return error) and
hopefully I'll actually have something to show in the next week or two.
If there's anyone else here who's also made an independent from-scratch
implementation I'd be interested to see their take on it.

- John Ripley.
--- >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@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.