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.

• Complete realtime sample rate lock

• Complete realtime 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:

• 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 realtime 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!