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?

So, enabling profiling makes the app segfault (or claim the .ogg file isn't valid, if compiled with `-O9'). Any ideas. This is using either `-pg' or `-p', which I'm using on all of the objects.

Without looking at the source, it sure sounds like running off the end of an arrary. Have you tried using efence or similar to watch for that?

Well, it doesn't segfault if I don't enable profiling, so I don't really think that that's the problem. Unless you know that enabling profiling can tweak that sort of error. I'm not too excited about trying to compile efence or whatever for the empeg, either, but if you think it might help....

A segfault is caused when you write to memory you didn't allocate. Usually what happens is that you run off the end of a string (missing null) or mis-calc an array index (<= on a for loop that should've had a <) and hit memory that isn't part of the array.

Often when it happens, you're overwriting memory that your program has already allocated for another variable. When that's the case, it doesn't cause a seg fault, but can cause strange and varying bugs.

With errors like that, changing compile options will often affect how the bug manifests itself. Since optimizing or profiling adds extra code inbetween yours, writting to stray memory will very likely cause different problems than it did before.

I had problems like that when compiling stuff for my TiVo and didn't have much trouble getting efence compiled for it. If you want a hand with that, I can try to compile efence for the empeg.

I suppose that's fair. I'll give efence a shot....

No joy. The efence-linked version runs with no complaints. (And an efence+gprof binary generates the same segfault.)

Here's my compilation of efence for the empeg. I had to make a couple mods to get it to compile, but nothing major. I've included the source as I've modified it and the binaries that I compiled. To compile this as-is, it works for me on my linux box to just run make without args. Note that the test progs with it will fail because they get cross-compiled too and won't run on the local machine.

All you really need from this is libefence.a. If you copy that to your lib dir (the one with your other empeg libs) or your current dir you can use it like this:

gcc -o mytest mytest.c -L. -lefence

assuming libefence.a is in the current directory.

Disclaimer: I haven't actually tried using this on my empeg yet ...but I expect it to work <fingers crossed>

strange... I've gotta get some sleep, but if I get a chance tomorrow eve, I'll give it a try.

If you haven't used efence before, I should mention that it won't fix your segfaults, just makes them easier to find. It's best used with a debugger, but I don't have gdb for the empeg (I tried to cross-compile for the tivo and it was a pain, then I found it was already available and quit trying). Without gdb, you can still put printf()s in for debugging. What efence does is cause your program to segfault immediately when the first problem occurs (making the bug easier to locate) rather than let your prog make a couple writes to memory that are mildly innocuous only to cause more problems later.

All I can say is don't spend too much time on these sources. I feel that FullPlay (the company releasing this particular library implementation) is being desceptive to not prominently mention that ivdev only decodes vorbis beta4 or earlier files. This is a significant limitation - Ogg Vorbis hit rc1 in June of 2001. So anything encoded since then won't play. Additionally, this code has issues, such as crash bugs. I actually asked John Ripley NOT to add vorbis support with this library - and he agreed it would be bad to have it only play old files, which will sound relatively bad, and fail to play current ones (John, I apologize for speaking for you).

The reason this "integerized decoder" exists is a messy tale. In my opinion FullPlay is just trying to do damage to Xiph.org (the non-profit org who authors Ogg Vorbis). Xiph.org sells their own (CHEAP) arm-capable decoder that plays all Vorbis files, has lower memory usage, etc.

I've told the Empeg folks that xiph.org produces a vorbis lib they could cheaply purchase to add support, and I understand that the suits probably balk at spending any money to add Vorbis support (for now). I know the developers at sonicblue really, really want vorbis support, so I don't mean to imply for a second that they are the problem. However, it is not the case anymore that "there are no integerized decoders available for Vorbis", so don't accept that answer from companies.

I believe that the powers that be will see the need to add Vorbis support to all their products sooner or later, all we can do is keep asking.

Jon

also as a note, last I heard profiling was broken under arm. It is possible that the most bleeding-edge cvs builds of gcc and gdb have fixed this, but as of a couple weeks ago, profiling caused seg faults.

Jon

Well, rat farts.

and I understand that the suits probably balk at spending any money to add Vorbis support (for now)

Well, that and the fact that money would be spent on a product no longer made, or sold by them. I'm suprised 2.0 has gone as far as it has considering so much is specific to the empeg and can't be tied to other products except in a general way. If empeg could convince SB to add Vorbis support to the Rio Reciever or Rio Central with a licence that would also cover the Rio Car at no extra cost, then we might see it.

The whole Beta 4 issue does have me bummed about it as well. I'm still encoding in MP3 like the rest of the house, as 95% of the music played now is via a non computer MP3 device.

I understand that, but you need to remember that they have a common codebase for their products. So adding vorbis support isn't just adding it to the Empeg, it'd be for all the Rio family of products.

Jon

The common codebase is great, but again it depends on the licensing. WMA was in the Rio Reciever and Rio Central long before the empeg not for any technical reason, but because of licensing issues. If SonicBlue precieves Vorbis on the empeg as an added expense, it won't happen any time soon.

More owners here need to buy one of the other products and request support for it. I'll probably write up something soon when I get my RioReciever. But asking for it on the empeg is a slim chance of success.

Don't make assumptions about what Xiph.org's licensing terms are.

edit: I didn't meant that to be as hostile as it sounded. I just mean I know the xiph folks quite well, and they understand that it's an entire line of products, and they're not as rigid as MS (understatement).

Jon

Do you think that asking SB for Ogg support on my ReplayTV 4000 might help? ;->