Porting SGI Audio Applications to Linux
The process used to port SGI audio applications was reflective of Linux's own distributed developments—a truly international collaboration dependent on Internet communication. It is still a work in progress, with improvements and extensions to the software being created and contributed by programmers around the world.
NoTAM is the Norwegian network for Technology, Acoustics and Music research located at the University of Oslo. Professor Oyvind Hammer of NoTAM wrote a series of applications designed to aid musicians and researchers in the analysis and representation of sound. Written originally for Silicon Graphics (SGI) computers, these applications utilize the graphics capabilities of the X Window System and make use of SGI's audio and sound file systems. Many applications offer basic and advanced editing features as well as sound file playback capability.
Although not traditionally thought of as an audio platform, Linux already has several sound file editing and processing systems. Packages such as MiXViews, Snd, XWave and the CERES Soundstudio are available for audio recording, editing and playback. Many other packages can be found on the Internet. The Linux Soundapps page (see Resources), which I maintain, is a comprehensive and up-to-date list of Linux-based audio applications.
The editing capabilities of the NoTAM software are of a different nature: edits are performed on the graphic results of a Fast Fourier Transform (FFT) of a sound file. Explaining FFTs is beyond the scope of this article, but the results of a transform are usually depicted in a “spectral representation”, i.e., a representation of frequency versus time. With the appropriate software, edits can then be made directly on the frequency content of a sound. Until recently, Linux had no such software, so porting the NoTAM applications to Linux was an attractive prospect.
When the NoTAM source code (made publicly available by Dr. Hammer and NoTAM) was examined, I noted that the graphics code consisted of plain X calls, and its sound support consisted of calls to the SGI-specific audio and audiofile libraries. Many of the applications were built with Motif. Since the necessary X libraries and LessTif (a freely available replacement for the Motif libraries) were already available, all that was needed in order to do the port were replacements for the audio and audiofile libraries. I contacted Dr. Hammer and asked him for permission to try porting the software to Linux, and with his gracious consent, the porting project began.
Looking over an excellent web page dedicated to SGI audio applications (maintained by Doug Cook), I noticed a sound-file editor named DAP (Digital Audio Processor), written by Richard Kent. DAP uses the XForms libraries, so I inquired about the possibility of a Linux port. Richard informed me that he had already written such a port, and when I mentioned I wanted to port some other software written for the SGI to Linux, he graciously supplied the code used in DAP to replace the SGI audio and audiofile libraries and headers. The Linux versions of libaudio.a, libaudiofile.a and their associated header files are virtually direct “plug-in” replacements, meaning I could leave the NoTAM sources relatively intact.
Armed with X11, Richard's replacement code and LessTif, I attempted my first port. I chose Dr. Hammer's Sono. This program analyzes a sound file and creates a PostScript sonograph of the spectral analysis. Since Sono does not display the graphics, instead relying on external display mechanisms, the port was fairly trivial, requiring only minor modifications.
With this first success, I moved on to another relatively straightforward program, PTPS, which creates a PostScript graph of a pitch-tracking analysis. PTPS also compiled easily with only small changes, so I decided to attempt a more substantial port.
Ceres is an FFT-based program, but its design goes far beyond the simplicity of Sono and PTPS. Ceres renders the FFT results into a graphic display which can then be edited directly and saved as a new sound file. The challenge in porting Ceres was primarily in the X programming. Since no real-time aspects were involved, there were no problems with audio playback. There were, however, problems with the use of variable-length Xt argument lists which, in theory, must be terminated with a NULL entry. The SGI compiler and libraries did not appear to require this NULL; however, the Linux GCC compiler and libraries were stricter, and Ceres would fail with a segmentation fault upon opening if the NULL was missing. In addition, a problem with different maximum random numbers (RAND_MAX) between SGI and Linux caused a crash when using the Random Sieve transform. Once these two problems were solved, the porting of Ceres was complete.
I then decided to do an even more ambitious port, Dr. Hammer's Mix package. Mix is a 9-channel audiofile mixer with graphic waveform displays, graphic volume and panning curves, a scripting language for complex mixes, and real-time effects processing. (See Figure 1.) Obviously, audio playback capabilities are exploited to the full. I thought porting Mix would be by far the most difficult challenge, yet with Richard's replacement libraries (and some judicious code-cutting), I was quickly able to compile the Mix application, and Linux now has an excellent 9-channel, sound file mixer.
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!
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Tech Tip: Really Simple HTTP Server with Python
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- Google's SwiftShader Released
- Parsing an RSS News Feed with a Bash Script
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
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