Porting SGI Audio Applications to Linux
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.
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.
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.
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 email@example.com.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Stunnel Security for Oracle
- SourceClear Open
- SUSE LLC's SUSE Manager
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Tech Tip: Really Simple HTTP Server with Python
- Non-Linux FOSS: Caffeine!
- Google's SwiftShader Released
- Doing for User Space What We Did for Kernel Space
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide