http://www.xiph.org/archives/vorbis-dev/0125.html

It appears the integer libraries have been released with a BSD-style license. Let's get it working!

fullplay=iobjects. What does the simple attribution requirement mean?

Ooooooh.

What does the simple attribution requirement mean?

Presumably it's one of those "This product contains an Ogg Vorbis codec written by such-and-such" sort of things.

Peter

PS. url seems to have changed to http://www.xiph.org/archives/vorbis-dev/200202/0125.html

I just prodded the guy to get his source. And I don't mean to belittle his efforts, but they're very Cygwin-specific, and I don't have a Cygwin environment set up. Does anyone have a Cygwin running and compiling for the empeg? I think that it should be pretty simple to get ogg123 running, just to test the speed, etc. I got the reference ogg123 running (albeit very slowly) with little problem, and the source he's given looks to be replacements for source files in that, so it ought to work.

Sorry about following up on this in General, BTW. If you have anything more to say than just ``I do'', please let's take this over to Programming.

Edit: Hmmm. Nevermind. I just got back in contact with him and it turns out that it's not a pseudo-patch to the reference sources, but a replacement set of sources linked directly in. That is, he had an application that used the reference Ogg Vorbis API and he replaced it with his new playback implementation. Maybe I can get it to work with ogg123 directly without needing the libraries at all.

Regardless, no Cygwin help needed right now....

Cygwin is just the GNU compilers targeted for x86 Windows console mode together with a gigantic abstraction layer DLL.

What does it need in libraries?

- Trevor

Again, nevermind. I was making several incorrect assumptions. I need nothing from Cygwin.

Ah okay. Was kind of wondering
Having Ogg Vorbis support would be quite neat but I'd need to actually get around to encoding stuff in that format.

- Trevor

In case anyone wants to know, I got the libVorbis decoder_example program running on my empeg. It just takes an Ogg Vorbis file as input and puts out a raw PCM file. No output through the empeg itself. Two problems: (1) There's something wrong and it sounds like the volume is being doubled somewhere. Very loud and horrible clipping. This is likely to be a simple bug somewhere and easy to fix. (2) The decoding takes 99% of the length of the file to occur. That is, the 2:45 track I used took about 2:43. And the load was at 0.99 (I ran it three times in a row, redirecting all output to /dev/null, and then checked /proc/loadavg). And that was at the command prompt with nothing else going on. So there's going to need to be more tweaking, most likely. I'd guess that this isn't going to happen as soon as we'd like.

Are you sure you have the integer math version? The referenced post says a 200 MHz StrongARM can do it using only 30% utilization, and as we all know we've got a 220 MHz SA110 on board... So either they're lying, you have a floating-point encoder, or there are some SERIOUS compiler optimizations that are being left out...

207.67Mhz StrongARM-1100 onboard.

Throwing `-O9' at everything that would take it sped it up to 2:09, but the CPU was still pegged. Notably, a multiplication routine wouldn't take the -O9, and I'm working on that.

Edit: Fixed the two bugs that prevented `-O9' from working on those multiplication routines and it cut another 2 seconds off, but the CPU is still pegged. (Not surprising since they're hand coded ARM assembler anyway.)

Oh, and it's definitely the fixed point version.

Er, no, 221MHz.

Current SA1110 parts don't go that fast, but we used the older, faster, 2.0v VCORE DE-S1100-DA parts.

Hugo

Oh, okay. I guess /proc/cpuinfo is slightly out of calibration, then.

Cheers

So they're just lying about the 30% thing?

Not necessarily. Their compiler might be doing a better job of optimization than mine. There's still a bug to work out, as the sound quality is awful, and that might have some impact. I don't know if decoder_example might be remarkably unoptimized. I should probably get someone else to compile it and see if it runs faster for them.

Note that I got ogg123 running on the empeg before using the reference floating point Ogg libraries and decoding took something on the order of 3 times real track time, so this is a vast improvement, regardless.

What kind of other differences are there between the SA1110 and the DE-S1100-DA? Is it just voltage or does the SA1110 have more arithmetic units or something like that?

...but the CPU was still pegged.

If you're letting it run full-speed and outputting to /dev/null for speed test, the CPU will always be pegged. But if they get 30% CPU usage, that should be (percentage of real-time playback) x (average CPU usage during decode) = 30%. So it should be finishing in 0:50. Even so, with your -O9 finishing in 2:09, that's 78% (a pretty good start).

Oh, okay. I guess /proc/cpuinfo is slightly out of calibration, then.

Just a shot in the dark here from a Linux user, but not a programmer. Isn't the correct CPU speed important for the kernel to have an accurate clock for timing? Could this be related at all to the lockups being tracked down in 2.0?

>Isn't the correct CPU speed important for the kernel

Yes, but mostly in the drivers. And 10% probably won't break anything. But one never knows..

The DE-S1100-DA is the intel part code for the 221MHz SA1100.

The SA1110 is in BGA package only, has SDRAM and a few bugfixes+ some small addons like faster cycle time options for I/O. There are no differences in the CPU core, just peripherals.

The Rio Central uses the SA1110.

Hugo

Hey Bitt,

Would you mind sending me what you have done so far. I emailed that Dan Conti guy and he pointed me to the sourceforge web site http://ivdev.sourceforge.net.

But all this consists of is source files. There is no makefile or even a main() routine. I had a quick crack at trying to get something together with no real luck

Thanks,

I'm taking this over to the Programming forum.

Bitt's right, take this over to the Programming forum. Locking this thread now.