[9fans] ogg vorbis player port?

[9fans] ogg vorbis player port?

[Axel Belinfante]

Just wondering if anyone already tried to port an ogg vorbis player?
I did a very birief, so far unsucessful, attempt at ape-porting Tremor,
which I'll probably retry, unless something has been ported already.

http://www.ogg.org/ogg/vorbis/

Axel.

Re: [9fans] ogg vorbis player port?

[Fco.J.Ballesteros]

[-- Attachment #1: Type: text/plain, Size: 46 bytes --]

I once did. But I think I deleted it. Sorry.

[-- Attachment #2: Type: message/rfc822, Size: 2666 bytes --]

From: Axel Belinfante <Axel.Belinfante@cs.utwente.nl>
To: 9fans@cse.psu.edu
Subject: [9fans] ogg vorbis player port?
Date: Fri, 04 Apr 2003 15:59:37 +0200
Message-ID: <200304041359.h34Dxce14178@zamenhof.cs.utwente.nl>

Just wondering if anyone already tried to port an ogg vorbis player?
I did a very birief, so far unsucessful, attempt at ape-porting Tremor,
which I'll probably retry, unless something has been ported already.

http://www.ogg.org/ogg/vorbis/

Axel.

Re: [9fans] ogg vorbis player port?

[rog]

> Just wondering if anyone already tried to port an ogg vorbis player?
> I did a very birief, so far unsucessful, attempt at ape-porting Tremor,
> which I'll probably retry, unless something has been ported already.

i just tried the same. i got it compiling, but i don't know if
it works yet. you have to laugh though; the README says:

	The C source in this package will build on any ANSI C compiler and
	function completely and properly on any platform.

i'm not sure that they know what "ANSI C" is!

e.g.
#if BYTE_ORDER==BIG_ENDIAN
	- "BYTE_ORDER" isn't defined by ANSI AFAIK

static inline ogg_int32_t MULT32(ogg_int32_t x, ogg_int32_t y) {
	- "inline" isn't ANSI (and they'd taken no steps to remove it)

ogg_int32_t **t = (ogg_int32_t **)alloca(sizeof(*t)*step);
	- alloca isn't defined in ANSI C

char *buffer=ogg_sync_bufferin(vf->oy,ibytes);
	- ogg_sync_bufferin returns uchar*

it's difficult to know what to do with all those carefully optimised
"inline" functions. for the time being i've left them as functions,
but i imagine for the smaller and most-often used ones
that might have a significant impact on performance.

in the mkfile, i used:
	CFLAGS=-c -I /386/include/ape -I/sys/include/ape '-DBYTE_ORDER=0' '-DLITTLE_ENDIAN=0' '-DBIG_ENDIAN=1' '-Dinline='
	CC=pcc

and changed each alloca to an amalloc + afree (in the right place)
it only took 45 minutes or so.

of course, it probably doesn't actually work!
but at least it compiles, which is a start...

  cheers,
    rog.