Index of /afs/sipb/user/mwhitson/Project/Ogg/98.9
Name Last modified Size Description
Parent Directory 04-Sep-97 03:06 -
DISTRIBUTION 03-Jun-96 14:59 5k
Makefile.in 04-Feb-97 01:08 1k
cmdline/ 04-Feb-97 02:21 -
configure 04-Feb-97 01:48 56k
configure.guess 23-Oct-96 09:00 17k
configure.in 04-Feb-97 01:47 3k
configure.sub 23-Oct-96 09:09 18k
install.sh 23-Oct-96 09:08 0k
libogg/ 04-Feb-97 02:21 -
* This is a source code distribution of the Xiphophorus OggSquish software *
* audio coder/decoder series 0.98 *
Xiphophorus OggSquish is an attempt both to create a flexible
compressed audio format for modern audio applications as well as to
provide the first audio format that is common on any and every modern
computer platform. Our focus is to make OggSquish *the* preferred
audio encoding choice of audio application designers on every computer
It is a sad truth that technical brilliance alone will not make a
software product successful; aggressive marketing virtually always
provides an edge over technical prowess in the marketplace, and the
engineers at Xiphophorus realize this. However, we treat competent
design as more than just an added bonus to aggressive sales.
OggSquish is software several years in the making; we've designed it
to remain cutting edge for the coming decade or more.
OggSquish development is ongoing and rapid; features and new releases
appear continuously; stay tuned for features the computer audio world
OggSquish is not freeware, shareware or a GNU GPL application. This
code is a commercial product, but a product that is freely available
and copyable for personal and non-profit use. See the file
DISTRIBUTION in this directory for details.
The libogg directory contains the full source for the 4th generation
OggSquish 0.98 libogg encapsulated audio coding/decoding library. The
app directory contains a small UNIX command line conversion
application that uses libogg to generate and play back Ogg format
bitstreams. The application is meant to provide a concrete example of
how to use the OggSquish library in real applications.
This distribution is targeted toward developers and programmers; if
you are uncomfortable building applications from source or porting
software to new platforms, please consider fetching binary executable
versions of the libogg library and/or OggSquish applications from
The libogg code is designed to compile and verify on any computer
platform with an ANSI C compiler. The provided makefile is for the
UNIX gcc compiler but should be easily modifiable (or not need
modification) for native UNIX and other C compilers. Libogg should
run *as-is* on *everything*.
The example application provided is a bit UNIX specific. This
application is being generalized to other platforms, but will require
some effort to port to other platforms at the moment. An X version of
the example app is also provided.
step 1: Configuring for the build
OggSQUISH now uses GNU autoconf to set up Makefiles. After untarring,
cd to the toplevel of the source directory and type:
Makefiles should then be built correctly to compile OggSQUISH on your
A note to gcc users; the optimization options chosen for gcc in
configure.in should not be frobbed unless you're a compiler god who
eats optimized assembly for breakfast and knows some nasty bugs have
been fixed. -funroll-all-loops, for example, will break Ogg miserably
in random ways as late as 2.7.2. Don't tempt fate; leave the options
where they are :-)
A note to SGI folks; SGI's cc actually produces faster code than gcc,
and the configuration script will choose cc (if available) even if it
can find gcc. Gcc can be forced by setting the CC variable in the
shell environment before running configure.
step 2: Testing libogg
Xiphophorus strongly recommends building the libogg selftests before
proceeding to build a production libogg or OggSquish application.
These test verify that OggSquish will compile and run correctly on
your platform; otherwise, your libogg could very easily generate
bitstreams that work on your machine but no other!
To run the selftests, type 'make selftest' in this directory. After
some compiling, the results of the selftests will appear. If all
tests pass, make selftest will finish with 'all selftests passed'. If
a selftest fails, contact us immediately such that we can correct the
failure on your platform.
step 3: Building libogg and the player application
To build a production libogg and application, simply type 'make'. To
build debugging versions of both, use 'make debug' instead. To build
only libogg, cd into the libogg directory before making. OggSQUISH
will not automatically install itself; the ogg and xogg executables
and ogg.1 manpage areleft in the toplevel source directory after the
'make clean' in the toplevel will clean out everything generated by a
make except the makefiles; also note that although install.sh is
empty, it is necessary to build due to an autoconf bug. DON'T DELETE
The player application is named 'ogg'; 'ogg -help' will return usage
help on the command line. The X version of the application is 'xogg'.
In a few places, the code needs 64 bit math. Libogg will return an
error if a script is loaded which requires 64 bit math (this would
happen when losslessly processing > 16 bit wide samples) and 64 bit
ints weren't available during compilation.
(Note; this section is written from the viewpoint of IBM PC/AT
compatible machine users. Xiphpohorus itself uses PCs running UNIX as
its primary development and testing platform).
The absolute minimum requirement for playback of compressed full CD
quality stereo (44.1kHz, 16 bit, 2 channels @ ~190kBytes/sec) is
targetted at exceptionally fast i486s (100-120MHz) and low end
Pentiums (60MHz and above). Playback of compressed CD quality
monophonic audio requires approximately a 486DX50. Lower sample
quality (a very common example would be 8bit 22kHz mono) requires
propotionately less computational power; generally any 486 will do.
Other platforms, such as the PowerMacintosh, SparcStation and Alpha,
tend to surpass the Pentium significantly in performance and thus can
fairly easily handle the processing requirements of OggSquish.
Processor speed alone does not determine OggSquish performance; Libogg
is an excellent stress test of a processor's floating point
capabilities, as well as a computer's secondary cache and hard disk
The 68k Macintoshes are a case in point. To put it mildly, the
FPU performance of a 68040 is abysmal. Samples that require 5 seconds
to encode on a low-end PowerMac could take full minutes on the fastest
Quadra, even with the FPU. Yes, it's really that slow. Taking the
engine's precision factor all the way down will help (by forcing Ogg
to use only integer math).
Although the OggSquish specification does not require floating point
arithmetic (it requires either floating point capability or 64 bit
precision integers), most desktop processors today (With the notable
exceptions of the UltraSparc II, Alpha and PA-RISC; the newest PowerPC
releases are also to be 64 bit) provide floating point that is
significantly faster than 64 bit integer arithmetic. For this reason,
Libogg makes heavy use of floating point math. Libogg would be
entirely crippled on a processor with no FPU (eg, 486SX, NexGen 586).
Fortunately, the looming majority of personal computers today have
built in floating point units.
Similarly, as OggSquish operates on fairly large vectors of data, L2
cache is extremely important to optimal performance; the on-chip data
cache of most processors is insufficient to enhance Ogg performance
whatsoever (The Pentium Pro is a notable exception; OggSquish *flies*
on the Pentium Pro due to its large L1 cache). 256k to 512k of data
cache for a Pentium is about the right amount; One of Xiphophorus'
older Pentium 66 machines (512k L2 cache) can easily outperform a
Pentium 90 when the P-90's L2 cache has been removed.
This last point is especially relevant in today's PC market where
'bargain basement' and 'family multimedia' computer systems are being
sold through warehouse and wholesale outlets with an impressive list
of features at first glance, but every possible corner cut upon closer
inspection. These machines, though Pentiums, are often sold with no
L2 cache; some are even sold with fake plastic inserts where the chips
should be to make it appear as if cache is installed! This lack of
cache will cripple the processors involved, typically reducing Ogg's
performance by 50%.
Disk throughput is also a consideration in benchmarking OggSquish. At
the highest quality levels, OggSquish is only processing a few hundred
kilobytes a second. Although most modern hard drives can sustain at
least a megabyte/sec of continual I/O (and some AV drives can handle
up to 40MBytes/sec), the choice of a disk controller will determine
how much of that performance is available. While 'dumb' disk
controllers such as IDE or EIDE boast impressive throughput and low
latency, the computer's processor is responsible for managing the
disk; if the processor is busy with something else (such as
OggSquish), performance will deteriorate substantially.
For this reason, self sufficient disk controller technologies such as
SCSI-II (or the much newer and less established 'FireWire') are
recommended for machines intended for heavy Ogg use; such a machine
would be substantially faster for any application that simultaneouly
demands processor and disk performance. As always, a small amount of
disk cache on the controller board will also help.