FireWire Audio by RME - Technical Background
»Technical Information Index
Overview on current FireWire audio solutions
RME is the only manufacturer not to use a third party FireWire audio technology. All other manufacturers
use dedicated all-in-one FireWire audio chips. As a result, their access to bugfixes and improvements is
more than limited. Here is a small overview of currently used chips:
BridgeCo: used by M-Audio, Terratec, ESI, Edirol, Presonus, Apogee, Tascam.
Philips AV LLC: used by Motu and Hercules.
Upcoming: a new chip from Texas Instruments, co-developed or supported by Echo.
Will be used in upcoming Echo and Mackie FireWire devices.
Upcoming: a new chip from TC, called Dice II. A few years ago TC have bought a
company that produced non-audio FireWire chips. Now this chip,
announced to be available more than a year ago, is said to finally
arrive. If so, it will be used in upcoming TC FireWire audio interfaces
Upcoming: a chip from Oxford Semiconductors called OXFW970. Not as feature-packed
as the other chips, but expected to be the cheapest one of all. It might
cause another flood of very cheap FW audio interfaces in 2005.
Differences between RME and all others
The picture shows the difference between our solution and all others. A dedicated FireWire
audio chip always includes everything except for the physical interface (the upcoming TI
chip will even include the PHY). The FireWire audio controller itself, including a special
RISC processor, and the so called Link Layer Controller are all combined in one chip. The
RISC processor is also (mis-) used to provide some kind of audio DSP functionality, but is
very limited in doing so. An alternative is to use an externally connected DSP, which then
allows for all kinds of effects and mix processing. The main disadvantage of an external
DSP is the limited transfer rate (bandwidth) between DSP and FW core, which limits the
numbers of processed channels significantly. For example, the matrix mixer of the HDSP
MADI, calculating 8192 volume levels simultaneously, is only possible because the
calculation takes place directly within the FPGA, as it can use the fastest RAM (internal
cells), and thus uses an otherwise not to be reached memory bandwidth.
RME have developed the FireWire audio core completely on their own. Additionally, as this solution
is within a FPGA, it can be changed, improved or bugfixed at any time. And our DSP functions, like
TotalMix and level metering, are performed by an extra, dedicated audio DSP, which also resides
within the FPGA.
The Link Layer Controller and Physical chip that we use are both from Texas Instruments. That should
guarantee a maximum compatibility, as TI's chipsets are widely spread and used, even in Apple
computers. The LLC is connected to the FPGA, giving us unlimited control on the available functions
of both chips. Otherwise the configuration of the Link Layer controller can usually only be changed
by the chip manufacturer, by providing a new firmware.
Typical Pro audio features
As you might imagine, the custom FireWire chips have been designed by developers who have
little knowledge of the superior features and functions of RME products. So these chips miss
a lot that can not be added later, even not by a firmware update. Let's have a look at some
typical Pro Audio features:
Lock to external signals in real-time
Support for varipitch/varispeed
Support for multiple units
Support for sample rates up to 192 kHz
Change of the buffer size in real-time
RME unique FireWire features
RME developed their FireWire audio controller with all the features in mind that RME PCI
interface cards have. The Fireface simply should work as if it were a PCI card. And we were
very successful with this approach. The following is a list of unique Fireface features that
are not found in current FireWire interfaces from other manufactures:
Complete real-time sample rate lock
Complete real-time sample rate control, even during playback/record
Complete start/stop control. No changed offset after reboot.
Extreme varispeed / external sync support, in all modes (DS / QS).
Reduced protocol overhead, by not sending CIP (Common Isochronous Packet format)
headers (AVC, mLan)
Working FireWire 800 solution
Working FW800 fix for Windows XP SP2
Latency change on the fly, while ASIO and GSIF are running
Hardware-based data packet check and drop correction
Data Packet Check and Drop Correction
An extraordinary feature that deserves a detailed explanation. There are two reasons
for clicks and drop outs:
Note that all FW interfaces in IBM-compatible computers are connected to the PCI bus! There is no
PC chipset with integrated FW available. Macs have FW integrated.
With the Fireface, the latter is more often showing up than before, as OHCI chips are more sensitive
to PCI bus performance problems than our Hammerfall PCI cards.
RME offer an easy way to differ between clicks caused by CPU overload (which is solved
by increasing the latency/buffer size), and the loss of complete FireWire data
packets. The FireWire communication between PC and Fireface includes watermarking of
the packets. The Fireface is able to detect whenever and how many packets got lost.
The number of errors detected is then displayed in the Settings dialog right below
'Video'. No packets lost - no display. The display will be reset whenever a new
This display allows to easily check the performance of any DAW with regards to transmission errors,
that are not an RME problem. They are the same for any other manufacturer, caused by the combination
of motherboard/FireWire controller. There is no way to change this performance aspect by the
On another note, the Error display can give confidence in working with otherwise often unpredictable
hardware. Start audio and fool around with windows, hard drives and network. If no error shows up in
the Settings dialog, the DAW is fully compatible and reliable, at least on the audio hardware side.
If clicks and drop outs occur without any error displayed, the DAW might be not powerful enough to
handle real-time audio, but that's a different story.
So far part one. Part two is even more interesting. Whenever a data packet gets lost (see above),
the current sample position shifts by the amount of lost samples. This way first the additional
safety buffer is eaten up, then the position gets so critical that the application has no time left
to process the buffer. Even at minimal CPU load the audible effect is like having 100% CPU load -
complete distortion. Next the position wraps around which makes latency rise dramatically.
When suffering from such effects, the best advice is to get a new computer. But of course RME tries
to get the most even out of such a situation. There are not much choices to resolve this
Stop the hardware. It depends on the stability and robustness of the audio
application wether it survives such a state.
Stop the hardware and restart it shortly thereafter (stop for about one second).
Better than before, but still might cause trouble with the audio
Stop and restart the hardware as quickly as possible.
That's exactly what RME do. The Fireface stops audio for about 3 ms (!), this way resetting the
sample position on every case of lost packages/drop out. It works fantastic, is an outstanding
unique feature of RME hardware, and once again shows the tremendous possibilities when not relying
on a fixed chip solution.
The quick restart corrects even the position of record data. Record a 5 minute track with (for
example) Cubase or Nuendo and intentionally cause a PCI overload. As a result, the recorded wavefile
will include a segment of 3 ms muted audio. All the following audio samples are still at the correct
position! A drop out of 3 ms even gives the chance to make the drop out inaudible. Adding some
samples at the beginning and the end of the mute segment, just 'drawing' them, or filling the mute
segment with a copied part makes the short drop out completely inaudible.
Conclusion and Summary
RME came late with their first FireWire solution, the Fireface 800. Nevertheless RME immediately
became the leader in FireWire audio. We have Pro features today, where others can only wait on newer
chips, that might fix something, might add something else, but most probably will not give the
superior solution that RME already provides. RME again became the reference, and looking at the
competitor’s solutions we will stay to be the reference for quite some time!
Copyright © Matthias Carstens, 2004.
All entries in this Tech Infopaper have been thoroughly checked, however no guarantee for correctness
can be given. RME cannot be held responsible for any misleading or incorrect information
provided throughout this document. Lending or copying any part of the complete document or
its contents is only possible with the written permission from RME.