Okay, to sum up:

There's a guy who has released fixed-point Ogg Vorbis decoding sources at http://ivdev.sourceforge.net/. (I'm assuming it's okay to say that. You can search for it at sourceforge, anyway.)

The sources he has are only .c and .h files. No Makefile or main() function. They are, basically, sources to a library that has the same API as the reference Ogg library.

However, they won't compile properly out of the box, at least not on my box. First, he has included one .c file (real.c) from several of the other .c files, which means that when you try to link them all in, the functions collide with themselves. So I've had to move that out. (I can't imagine how this worked for him. Any ideas?)

In addition, some of the embedded assembler code in there is slightly malformed, and I can see why it might work with his compiler, by chance, but it didn't work with mine. (It has to do with using registers versus memory locations and how ARM assembler deals with direct and indirect addressing. If you understand that, it should be easy for you to understand what I've changed.)

There were also a couple of syntactical things I changed that probably don't make a hell of a lot of difference in the end, but made it easier for me to debug those initial problems.

All of these changes that I've made so far are available at http://www.beaglebros.com/empeg/ogg-int-fix.diff. Note that you'll also have to rename all of his .cpp files to .c files before applying that patch. I've got some real issues with how he's organized his code, but he got a lot further than I did, so who am I to complain? (Nobody.)

Right now, I can compile the decoder-example.c file that comes with libVorbis (with a one or two minor changes -- you should be able to figure it out) and get it to run on the empeg. But there are two problems. First, it doesn't produce correct output. It's recognizable, but it sounds like the amplitudes are twice what they should be and it's clipping horribly (in fact, decoder-example says as much when it's run). I don't yet know where this bug is. Second, it takes about 2:09 to decode a 2:45 song (my test case being Millencolin - No Cigar) at, basically, 100% CPU utilization. This is significantly faster than real time, but the player wasn't running, which means there were no visuals playing, etc. Plus, the announcement claimed about 0.33 realtime-CPUs to decode.

If anyone else wants to play around with what I've done so far, feel free. You might try getting ogg123 to work. Perhaps there's a lot of poor optimization in decoder_example. The next thing I plan to do is see if I can figure out where that clipping is coming from. It's possible that the bug that's causing that is also causing the poor performance.

Also note that I'm not sure that the ``corrections'' I've made are correct. I think that I've just fixed some naming and addressing problems, but it's easily possible that I've introduced bugs. (If you want to check, the first thing I'd try is removing the newlines after the labels in the assembly routines. I think I read that there might be some memory positioning issues with having labels on different lines than the instructions, and I did introduce those newlines.)

Well, that's all I can think of right now. Questions?