Firewire Audio Made by RME - Technical Background

 

Firewire Interfaces - Made by RME

Firewire Interfaces - Made by RME: Optimal Hardware adaption, a unique Low-Latency-Concept and a high grade of performance and compatibility. It´s no surprise customers and testers respect RME Fireface interfaces as the reference for Firewire audio, with first class sound, minimal latencies, stability and the first choice for mobile recording.

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 for sure.

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 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
• Offset-free record/playback
• 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
• Hardware-based data packet check and drop correction
• Latency change on the fly, while ASIO and GSIF are running

Data Packet Check and Drop Correction

An extraordinary feature that deserves a detailed explanation. There are two reasons for clicks and drop outs:

• Not enough time left for the audio engine to process the data. This is easily solved by increasing the buffer size (latency).
• Loss of data due to overloads on and flawed performance of the PCI bus.

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 playback starts.

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 driver.

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 problem:

• 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 application.
• 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.

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 or the complete document or its contents is only possible with the written permission from RME