RME制造的火线接口——硬件的最理想搭配，具有独特的低延迟概念以及高级的兼容性和性能。许多客户和测试人员将RME的Fireface接口作为火线接口的参考标准。它拥有顶级的音质、最小的延迟、超级的稳定性，是移动录音的首选。

现有火线音频解决方案概览

RME是唯一一家不使用第三方火线音频技术的厂商，其他所有的厂商都使用专用的一体化的火线音频芯片。因此，它们的错误更正和改进都会受到限制。下面对现有的芯片进行一下简述：

BridgeCo: 被M-Audio、Terratec、ESI、Edirol、Presonus、Apogee和Tascam采用。

Philips AV LLC: 被Motu和Hercules采用。

即将发布: 来自德州仪器公司（Texas Instruments）的新芯片，由Echo支持并合作开发的。将会用于即将上市的Echo和Mackie火线设备。

即将发布: 来自TC的新芯片，叫做Dice II。几年前，TC收购了一家生产非音频火线芯片的公司，它们声称现在这个芯片已经可以用于音频。因此，在即将来临的TC火线音频接口中肯定会使用。

即将发布:来自牛津半导体（Oxford Semiconductors）的芯片，叫做OXFW970. 并不像其他芯片一样集成大量功能，但有望成为最便宜的芯片。这将在2005年引发低价火线音频接口的又一狂潮。

RME与其他产品的区别

下图展示了我们与其他解决方案的区别。专业的火线音频芯片包括了除了用于物理接口（即将发布的TI芯片甚至包括物理接口功能）的所有功能。火线音频控制器，包括特殊的RISC处理器和所谓的链路层控制器，都集成在一个芯片上。RISC处理器也用于提供某些音频DSP功能，但功能有限。解决方法通常是连接外部DSP，进行各种效果和混音处理。外部DSP的主要缺点是DSP与火线设备之间有限的传输速率（带宽），这会严重限制可以处理的通道数目。例如，HDSP MADI的矩阵混音器，可同时计算8192音量级，这是因为计算直接发生在FPGA中，可以使用最快的RAM，因此使用其他产品的不能达到这样的存储带宽。

RME自主研发了火线音频核心。另外，作为FPGA的解决方案，它可以随时进行修改、改进和或修正。我们的DPS功能，例如TotalMix和电平表，都使用的是FPGA中额外专用的音频DSP。

链路层控制器（LLC）和物理芯片都是来自德州仪器公司的。由于TI的芯片广泛被使用，甚至苹果电脑都采用了，因此应该能够保证最大的兼容性。LLC与FPGA连接，为我们提供了对两个芯片有用功能无限制的控制。另外，LLC的配置只能通过芯片厂商提供一个新的固件来进行更改。

典型专业音响的特性

正如您能够想象得到的，通常火线芯片都是由一些对RME产品的功能和优越特性了解甚少的开发人员设计的。所以这些芯片缺少了很多功能，不能稍后添加甚至不能固件升级。让我们来看看一些典型专业音响的特性：

• 可实时锁定外部信号
• 支持varipitch/varispeed
• 无偏移录音/重放
• 支持多个单元
• 支持最高采样率192kHz
• 可实时更改缓冲区大小

RME独特的火线特性

RME开发了自己的火线音频控制器，包含了RME PCI音频卡所具有的所有音频特性。Fireface的运行就好像它是一个PCI卡，我们非常成功地达到了预期。下面列出了现有其他厂商火线音频接口所不具备的，RME Fireface的独有的产品特点：

• 完全实时的采样率锁
• 完全实时的采样率控制，即使在重放和录音过程中也可以
• 完整的开始/结束控制，重启后补偿没有变化。
• 所有模式(DS / QS)下，极端的varispeed      / 外部同步支持。
• 减少的协议开销，不发送CIP (Common Isochronous Packet格式) 头文件(AVC, mLan)
• 使用FireWire 800解决方案
• 使用Windows XP SP2下的FireWire      800修复
• 基于硬件的数据包检查和数据丢失校正
• 在ASIO和GSIF运行中进行延迟更改

这个杰出的特性需要详细解释一下。出现咔哒声和数据丢失有两个原因：

• 留给音频引擎来处理数据的时间不够多。这可以通过逐渐变大的缓冲区（延迟）来解决。
• 由于过载导致的数据丢失以及PCI总线有缺陷的性能。

需注意的是，所有与IBM公司机器兼容的电脑的火线音频接口都是与PCI总线连接的，没有有效的带有集成火线的PC芯片集。Mac带有火线集成。

与Fireface一起，后者现在比以前更常见，因为OHCI芯片比我们的Hammerfall PCI卡对于PCI总线性能问题更敏感。

RME提出了一种简单的方法来区分由CPU过载（可通过增加延迟/缓冲区大小来解决）引起的咔哒声和完整火线数据包的丢失。在PC和Fireface之间的火线通信包含了数据包的水印。Fireface能够检测数据包何时丢失的，丢失了多少。检测到的错误数目可以在“视频”下面的“设置”对话框中显示。没有数据丢失则不显示。当新数据包开始时，显示会重置。

这个显示可以很方便地检测到任何会出现传输错误的DAW的性能，这不是针对RME的，对于由于主板/火线控制器的结合引起错误的其他厂商设备也同样适用。无法通过驱动来更改性能。

另外值得注意的是，错误显示可以在使用难以预测的硬件时更加肯定和确定。Windows、硬件驱动和网络开始工作后，如果在“设置”对话框中没有错误显示，那么这个DAW就是全兼容的、可靠的，至少在音频硬件部分是这样的。如果出现了咔哒声和数据丢失，但并没有错误显示，说明这个DAW还没有足够的能力来实时处理音频，但这就是另一码事了。

到此只是第一部分，第二部分就更有意思了。不管数据包有没有丢失（见上），当前的采样位置根据丢失采样点的数量而变化。首先，这样会使得额外的安全缓冲区减小，其次这个位置就变得很关键，应用程序就没有剩余的时间来处理缓冲区。即使是最小的CPU负载，听起来就像有100%CPU负载——完全失真了。下一个位置回绕，使得延迟大幅度增加。

当遭遇这样的影响时，最好的建议就是换一台新电脑。但是即使在这种情况下，RME也试图做到最好，解决这个问题的方法不多：

• 停止硬件。这取决于音频应用程序的稳定性和健壮性是否能够延续这样的状态。
• 停止硬件并（约1s后）重启。比之前要好，但音频应用程序仍然会出现问题。
• 停止硬件并以最快速度重启。

这就是RME在做的事情。Fireface停止一个音频只需3ms，这样可以在任何丢失数据包的情况下对采样位置进行重置。它运行得很好，是RME硬件杰出的独特产品特性，再次展示了在不依赖固定芯片解决方案的条件下解决问题的巨大可能性。

快速重启甚至可以校正录音数据的位置。例如用Cubase或Nuendo录制一个5分钟的音轨，故意产生一个PCI过载。结果是，wav文件会出现3ms的静音段，剩下的音频采样点都在正确的位置。3ms的数据丢失还是有机会可以使它不被听见，在静音段的开始和结束的地方增加一些样本，你可以“画”出来，也可以复制一些样本点来填充静音段，这样就完全听不出来了。

总结

RME的第一个火线解决方案——Fireface 800来得迟一些，但RME立即成为火线音频的领军者。我们今天拥有专业的功能，而其他人还在等待更新的芯片，新的芯片可能会修正一些问题，增加一些功能，但不会具有RME已经提供了的卓越解决方案。RME再次成为了参照标准，看看其他竞争者们的解决方案，在相当长的时间内我们都将保持这个参照标准的地位。

版权 © Matthias Carstens.

在这个技术信息说明的所有条目都已彻底检查，但不能保证没有任何错误。RME不为此文章中任何误导或错误的信息负责。借用或复制整个文档或部分内容需得到RME的书面许可。