[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: What now, tech?
The SGI O2 has been touted as the "best" Unix platform for audio, but I don't
know of anyone who has actually used one. A lot of people have them on order,
including one of my colleagues here at UIUC.
I would like to know how fast the O2 really is. I did some benchmarking of
the SGI Indigo, the IBM RS-6000, and the DEC Alpha a couple of years ago and
found them to be about 3, 5, and 9 times faster than the NeXT 040. Only the
DEC Alpha was close to *one* order of magnitute faster than the NeXT. (an order
of magnitude being a factor of 10)
The Power Mac is also a fast machine, and it has a lot of software. I thought
I might be able to have the best of both worlds by installing the Unix system
MachTen 4.0 on our PM 7500 (with 601 CPU) and porting our Unix programs Music
4C and SNDAN to it. This system rides on top of the Mac OS, so one can quickly
switch from MachTen to any Mac App. On straight ahead computation, sound
analysis benched at about 3 times as fast as the NeXT 040, putting it about on
the level of the Indigo, but I found the Unix system to be extremely clunky. It
was very slow to respond, particularly on remote login, and worse, it crashed
much too often. But this was with only 16 M RAM, and I've been told that
bringing it up to 64 M will fix the problem. The memory should arrive soon, and
we'll see soon how this affects the Unix performance.
Both the O2 and the Power Mac have built in stereo analog sound input/output,
and the O2's is probably better, but what about AES/EBU to drive DAT machines?
The Indigo had the option for its backup drive to double for this purpose, but
I've heard it wasn't perfectly reliable. The O2 is supposed to have an
8-channel ADAT board coming, but what if you only want two channels? Does
anyone know of a good solution for AES/EBU? Will the DAT backup drive obviate
this need?
We can hang on to our NeXT/AD64x AES/EBU setup for this purpose, but if we
switch to the world of SGIs or Power Macs, we will need a more manageable
solution.
Jim Beauchamp
University of Illinois
j-beauch@uiuc.edu