Porting SGI Audio Applications to Linux
nick...@googlemail.com
From Issue #53
September 1998
Sep 01, 1998 By David Phillips and Richard Kent
inAudio/Video
This article describes the process of porting a variety of audio
applications from the SGI platform to the Linux operating system.
Audio and Audiofile Libraries
Most, if not all, SGI audio applications make extensive use of the
excellent audio and audiofile libraries supplied with IRIX. The
audiofile library provides an API primarily designed to allow
effortless loading and saving of AIFF audio files. The audio library
is designed to allow straightforward audio input and output as well as
control global audio settings. In order to make porting as painless as
possible, replacement libraries had to be written for the Linux
operating system.
The audiofile library was tackled first. Since this library simply has
to perform file I/O based on the calls made, it was relatively
straightforward to set up the necessary AIFF structures and to
initialize, load and save these structures as necessary. However,
because samples are read from and written to disk one sample frame at
a time, this straightforward port of the audiofile library is
relatively slow. In addition, only AIFF files are supported—compressed
AIFF-C and WAV format files are not.
The audio library was a more demanding port, requiring extensive
investigation into the facilities provided by the Open Sound System
(OSS/Free) driver which is, by default, compiled into the Linux
kernel. The basic process when using OSS involves opening /dev/dsp and
either writing sample data directly to the device or reading from the
device. In addition, opening /dev/mixer allows control over the global
audio settings.
The Linux conversion basically sets up internal sample queues and
provides facilities to transfer these sample queues to and from /dev/
dsp. Most complications which arose were due to the many different
sample formats (resolution and number of channels) supported by both
the audio library and the OSS driver, thus requiring many different
data conversions on input and output.
The resulting audio library on Linux is very much a “brute force”
conversion and differs significantly from the SGI-based library,
despite the almost identical API. The main difference is that the
Linux audio library is not threaded whereas the SGI-based library
constantly inputs and outputs sample frames from a cyclic queue in the
background. As a result, the API user needs to be aware that samples
must be constantly written to or read from the device to avoid audio
glitches. Also, when finishing sample playback, blank samples must be
written to the device to force the remaining sample queue to play
before closing the device. The other main difference is that only one
audio “port” may be open at any given time, due to the exclusive
nature of opening /dev/dsp.
Compiler Differences
The default SGI compiler is quite different from gcc, which is the
most commonly used compiler on Linux. More specifically, the SGI
compiler is “relaxed” and not nearly as strict as gcc. This manifests
itself in several ways, which must be considered when porting software
from one platform to the other.
The most obvious difference is that explicit casting is often required
on gcc to avoid warnings and errors which do not occur when using the
SGI compiler. Two examples are shown here.
Default SGI compiler accepts:
int x = 3.2;
int *y = calloc (10,sizeof (int));
Linux gcc requires:
int x = (int) 3.2;
int *y = (int *) calloc (10,sizeof (int));
Correct link order is also more important when using the Linux gcc
linker. The default SGI linker appears to place little importance on
the order of link components (object files and libraries) when
linking, as long as all “loose ends” are tied up by the end of the
linking process. The Linux gcc linker, which I freely admit to not
fully understanding, is much stricter and frequently requires
reordering of link components and sometimes even duplication of linked
libraries.
Another major difference between the SGI default compiler and gcc
arises when combining C and C++ files where the C files cannot, for
syntactic reasons or otherwise, be passed through the C++ compiler.
When using the default SGI compiler, the command for compiling both C
and C++ files is CC, so there is no need to explicitly specify linkage
specification using the extern C construct. When using the gcc
development environment, the command to compile C files is gcc and the
command to compile C++ files is g++; thus, the linkage specification
must be specified when referring to C-based functions within C++
files, or else linking will fail due to C++ name mangling.
Variable Argument Lists
One final major difference between SGI and Linux development
environments is that of variable argument lists for Xt and Motif
function calls. The Xt toolkit provides the developer with basic GUI
constructs which may be used directly to create a user interface. In
addition, Motif and LessTif use the Xt toolkit to provide a higher-
level API for constructing user interfaces.
Within these toolkits are functions which have a variable number of
arguments, much like the standard printf system call. Unlike printf,
these functions require a null entry to terminate the argument list.
However, in the SGI development environment, these null entries are
optional and SGI developers frequently forget to terminate the
argument list with such an entry. This does not cause a problem on SGI-
based systems, but if this same code is then compiled in a Linux
environment, the resulting executable will almost certainly core dump
upon execution. The fix is simply to add the missing null entries to
the relevant calls.
Resources
David Phillips is a composer/performer living in Ohio. He has been
involved with personal computers since 1985, when he first saw and
heard a demonstration of MIDI music-making. Recent computer-music
activities include an ambient composition for the artist Phil Sugden,
lecturing on computer-music programming languages at Bowling Green
State University, and maintaining the “official” version of Csound for
Linux. Besides playing music and programming, Dave enjoys reading
Latin poetry, practicing t'ai-chi-ch'uan, and any time spent with his
lovely partner Ivy Maria. He can be reached via e-mail at
dlp...@bright.net.
Richard Kent is a professional C/C++/ActiveX developer currently
working in Edinburgh, Scotland on traffic analysis and simulation
software for both UNIX and NT. Richard has a very keen interest in the
field of music technology and is the author of DAP (Digital Audio
Processor)--a popular sample editor for Linux, SGI and Solaris
operating systems. He can be reached via e-mail at r...@quadstone.com.