移植 SGI 音频应用程序的过程反映了 Linux 自身分布式开发的特点——真正依赖互联网通信的国际合作。它仍然是一项正在进行的工作，世界各地的程序员不断创建和贡献软件的改进和扩展。

NoTAM 是位于奥斯陆大学的挪威技术、声学和音乐研究网络。NoTAM 的 Oyvind Hammer 教授编写了一系列应用程序，旨在帮助音乐家和研究人员分析和表示声音。这些应用程序最初是为 Silicon Graphics (SGI) 计算机编写的，利用了 X Window 系统的图形功能，并使用了 SGI 的音频和声音文件系统。许多应用程序提供基本和高级编辑功能以及声音文件播放功能。

尽管 Linux 传统上不被认为是音频平台，但它已经拥有多个声音文件编辑和处理系统。MiXViews、Snd、XWave 和 CERES Soundstudio 等软件包可用于音频录制、编辑和播放。在互联网上可以找到许多其他软件包。我维护的 Linux Soundapps 页面（参见“资源”）是基于 Linux 的音频应用程序的全面且最新的列表。

NoTAM 软件的编辑功能本质上有所不同：编辑是在声音文件的快速傅里叶变换 (FFT) 的图形结果上执行的。解释 FFT 超出了本文的范围，但是变换的结果通常以“频谱表示”来描绘，即频率与时间的表示。使用适当的软件，然后可以直接对声音的频率内容进行编辑。直到最近，Linux 还没有这样的软件，因此将 NoTAM 应用程序移植到 Linux 是一个有吸引力的前景。

当检查 NoTAM 源代码（由 Hammer 博士和 NoTAM 公开提供）时，我注意到图形代码由纯 X 调用组成，其声音支持由对 SGI 特定的音频和 audiofile 库的调用组成。许多应用程序是用 Motif 构建的。由于必要的 X 库和 LessTif（Motif 库的免费替代品）已经可用，因此移植所需的只是音频和 audiofile 库的替代品。我联系了 Hammer 博士，并征得他的同意尝试将该软件移植到 Linux，并在他慷慨的同意下，移植项目开始了。

在浏览一个专门介绍 SGI 音频应用程序的优秀网页（由 Doug Cook 维护）时，我注意到一个名为 DAP（数字音频处理器）的声音文件编辑器，由 Richard Kent 编写。DAP 使用 XForms 库，因此我询问了移植到 Linux 的可能性。Richard 告诉我他已经编写了这样的移植版本，当我提到我想将一些为 SGI 编写的其他软件移植到 Linux 时，他慷慨地提供了 DAP 中用于替换 SGI 音频和 audiofile 库和头文件的代码。Linux 版本的 libaudio.a、libaudiofile.a 及其相关的头文件实际上是直接的“插件”替代品，这意味着我可以相对完整地保留 NoTAM 源代码。

有了 X11、Richard 的替换代码和 LessTif，我尝试了我的第一次移植。我选择了 Hammer 博士的 Sono。该程序分析声音文件并创建频谱分析的 PostScript 声谱图。由于 Sono 不显示图形，而是依赖外部显示机制，因此移植非常简单，只需要进行少量修改。

有了第一次成功，我继续移植另一个相对简单的程序 PTPS，它创建一个音高跟踪分析的 PostScript 图形。PTPS 也很容易编译，只需要进行少量更改，所以我决定尝试更实质性的移植。

Ceres 是一个基于 FFT 的程序，但其设计远远超出了 Sono 和 PTPS 的简单性。Ceres 将 FFT 结果渲染到图形显示中，然后可以直接编辑并另存为新的声音文件。移植 Ceres 的挑战主要在于 X 编程。由于不涉及实时方面，因此音频播放没有问题。但是，可变长度 Xt 参数列表的使用存在问题，理论上，可变长度 Xt 参数列表必须以 NULL 条目终止。SGI 编译器和库似乎不需要这个 NULL；但是，Linux GCC 编译器和库更严格，如果缺少 NULL，Ceres 将在打开时出现段错误。此外，SGI 和 Linux 之间不同的最大随机数 (RAND_MAX) 问题导致在使用随机筛变换时崩溃。一旦解决了这两个问题，Ceres 的移植就完成了。

然后，我决定进行更雄心勃勃的移植，Hammer 博士的 Mix 软件包。Mix 是一个 9 声道音频文件混音器，具有图形波形显示、图形音量和平移曲线、用于复杂混音的脚本语言和实时效果处理。（见图 1。）显然，音频播放功能得到了充分利用。我认为移植 Mix 将是迄今为止最困难的挑战，但借助 Richard 的替换库（以及一些明智的代码剪切），我很快就能够编译 Mix 应用程序，现在 Linux 拥有一个出色的 9 声道声音文件混音器。

图 1. Mix 截图

我将移植的程序及其源代码放在俄亥俄州鲍ling Green State University 音乐技术系的 FTP 服务器上，然后我将我们的成功通知了 Hammer 博士（他对我们取得如此大的成就感到高兴），并且我还告知 NoTAM 他们的软件现在可用于 Linux。NoTAM 获取了软件包并将它们放在他们的服务器上，使所有人都可以轻松访问这些应用程序。我还向 Csound 邮件列表和 comp.os.linux.announce 发送了通知，以告知 Linux 社区这些软件包的可用性。

自从发布公开版本以来，开发工作仍在继续。瑞典作曲家 Reine Jonsson 基于我们的源代码包和 Richard 的库代码，贡献了一个 Mix 版本，该版本现在可以处理流行的 WAV 格式声音文件（原始 Mix 以及其他 NoTAM 软件包仅支持 AIFF 格式文件），同时缩短了加载时间并提高了播放流畅度（这在我的 486/120 上是一个关键因素）。Johnathan Lee 正在开发一个名为 Ceres2 的新版本 Ceres（见图 2），并且应该在本文发表时提供 Linux 移植版本。

图 2. Ceres 截图

仍然可以进行改进：到目前为止移植的应用程序相当稳定，但有时会无缘无故地崩溃。在某些情况下，并非所有原始功能都可用，特别是如果软件包使用了 SGI 音频硬件功能特定的例程。例如，Mix 源代码包含对 SGI MIDI 接口的调用，但这些调用的替换库尚未编写。目前，我不得不禁用 Mix 源代码中的 MIDI 控制代码。我收到了大量用户的邮件，他们表示有兴趣看到更多这样的移植开发，我非常希望我们很快就能找到 SGI MIDI 库的替代品，添加到已经支持的音频和 audiofile 库中。

必须提到的是，NoTAM 软件包不是唯一可用于可能移植的高质量 UNIX 音频处理软件的来源。Guenter Geiger 成功移植了 Paul Lansky 的 RT，这是另一个具有出色脚本功能的实时声音文件混音器。Paul Lansky 的 Ein（DSP 草稿本）、Mara Helmuth 的 Patchmix（Cmix 音频处理语言的图形修补器）和 Russell Pinkston 的 XPatchWork（类似于 Patchmix，但使用 Csound 语言）的移植工作正在进行中。许多其他与音频相关的软件包可用于 Linux，感兴趣的读者应查看 Linux Soundapps 网页，以获取不断更新和全面的列表。

当我第一次使用 Linux 时，我对它的可能性感到兴奋，但对缺乏高质量的声音处理软件感到沮丧。尽管如此，源代码的可用性和 Linux 社区帮助开发音频应用程序的意愿激励了我。由于我不是程序员，因此我依靠世界各地 Linux 用户的技能、经验和建议。与 Linux 本身一样，这些项目是通过分布式协作努力开发的，严重依赖互联网进行所有通信，并使用免费提供的工具和库构建。

感谢 Oyvind Hammer 博士、Richard Kent、LessTif 开发人员和 XFree86 项目，Linux 音频软件的数量和质量几乎每天都在增长。我鼓励感兴趣的开发人员与我联系，让我知道他们正在做什么或希望做什么。许多项目正在等待希望贡献他们的才能和兴趣以发展迅速的 Linux 音频和音乐软件基础的开发人员。

作者：Richard Kent

当我第一次听说 Dave 将音频应用程序从基于 SGI 的环境移植到 Linux 的项目时，我非常有兴趣参与其中——特别是由于 UNIX 音频应用程序的匮乏是编程数字音频处理器的主要原因。我最初为基于 SGI 的系统实现了 DAP，但在 Dave 联系我之前不久，我成功地将 DAP 移植到基于 Linux 的环境中运行。（见图 3。）这种经验在移植 NoTAM 应用程序时帮助很大。此侧边栏旨在详细介绍尝试此类移植时的三个主要技术考虑因素。

图 3. 数字音频处理器

大多数（如果不是全部）SGI 音频应用程序都广泛使用了 IRIX 提供的出色的音频和 audiofile 库。audiofile 库提供了一个 API，主要旨在轻松加载和保存 AIFF 音频文件。音频库旨在允许直接的音频输入和输出以及控制全局音频设置。为了使移植尽可能轻松，必须为 Linux 操作系统编写替换库。

首先处理的是 audiofile 库。由于此库只需要根据发出的调用执行文件 I/O，因此相对容易设置必要的 AIFF 结构，并根据需要初始化、加载和保存这些结构。但是，由于样本一次一个样本帧地从磁盘读取和写入磁盘，因此 audiofile 库的这种直接移植相对较慢。此外，仅支持 AIFF 文件——不支持压缩的 AIFF-C 和 WAV 格式文件。

音频库是一个更苛刻的移植，需要广泛研究默认编译到 Linux 内核中的 Open Sound System (OSS/Free) 驱动程序提供的功能。使用 OSS 时的基本过程包括打开 /dev/dsp，然后将样本数据直接写入设备或从设备读取数据。此外，打开 /dev/mixer 可以控制全局音频设置。

Linux 转换基本上设置了内部样本队列，并提供了将这些样本队列传输到 /dev/dsp 和从 /dev/dsp 传输的工具。出现的大多数复杂情况是由于音频库和 OSS 驱动程序支持的许多不同的样本格式（分辨率和通道数），因此需要在输入和输出上进行许多不同的数据转换。

Linux 上生成的音频库在很大程度上是“蛮力”转换，并且与基于 SGI 的库有很大不同，尽管 API 几乎相同。主要区别在于 Linux 音频库不是线程化的，而基于 SGI 的库不断地在后台从循环队列输入和输出样本帧。因此，API 用户需要注意，必须不断地向设备写入或从设备读取样本，以避免音频故障。此外，在完成样本播放时，必须将空白样本写入设备，以强制剩余的样本队列在关闭设备之前播放。另一个主要区别是，由于打开 /dev/dsp 的独占性质，任何给定时间只能打开一个音频“端口”。

默认的 SGI 编译器与 gcc 非常不同，后者是 Linux 上最常用的编译器。更具体地说，SGI 编译器是“宽松的”，并且远没有 gcc 那么严格。这以多种方式体现出来，在将软件从一个平台移植到另一个平台时必须考虑这些方式。

最明显的区别是，通常需要在 gcc 上进行显式转换，以避免在使用 SGI 编译器时不会发生的警告和错误。此处显示了两个示例。

默认 SGI 编译器接受

int x = 3.2;
int *y = calloc (10,sizeof (int));

Linux gcc 需要

int x = (int) 3.2;
int *y = (int *) calloc (10,sizeof (int));

当组合 C 和 C++ 文件时，SGI 默认编译器和 gcc 之间会出现另一个主要区别，其中 C 文件由于语法原因或其他原因而无法通过 C++ 编译器传递。当使用默认的 SGI 编译器时，编译 C 和 C++ 文件的命令是 CC，因此无需使用 extern C 构造显式指定链接规范。当使用 gcc 开发环境时，编译 C 文件的命令是 gcc，编译 C++ 文件的命令是 g++；因此，在 C++ 文件中引用基于 C 的函数时，必须指定链接规范，否则由于 C++ 名称修饰，链接将失败。

SGI 和 Linux 开发环境之间的最后一个主要区别是 Xt 和 Motif 函数调用的可变参数列表。Xt 工具包为开发人员提供了基本的 GUI 构造，可以直接使用这些构造来创建用户界面。此外，Motif 和 LessTif 使用 Xt 工具包来提供更高级别的 API，用于构建用户界面。

在这些工具包中，有一些函数具有可变数量的参数，很像标准的 printf 系统调用。与 printf 不同，这些函数需要一个空条目来终止参数列表。但是，在 SGI 开发环境中，这些空条目是可选的，SGI 开发人员经常忘记使用此类条目终止参数列表。这在基于 SGI 的系统上不会引起问题，但是，如果在 Linux 环境中编译相同的代码，则生成的exe文件几乎肯定会在执行时核心转储。解决方法很简单，只需将缺少的空条目添加到相关调用中即可。

资源