Firewire Audio - RME Audio Fireface 400 User Manual

Therefore, in a digital loopback test a negative offset of about 3 ms occurs. This is no real
problem, because this way of working is more than seldom, and usually the offset can be com-
pensated manually within the application. Additionally, keep in mind that even when using the
digital I/Os usually at some place an AD- and DA-conversion is involved (no sound without...).
Note: Cubase and Nuendo display the latency values signalled from the driver separately for
record and playback. While with our former cards these values equalled exactly the buffer size
(for example 3 ms at 128 samples), the Fireface displays an additional millisecond – the time
needed for the AD/DA-conversion. Playback even shows another millisecond added – see
Safety Buffer.
Safety Buffer
FireWire audio differs significantly from RME's previous DMA technology. DMA access is not
possible here. To be able to transmit audio reliably at lower latencies, FireWire requires a new
concept – the Safety Buffer. The Fireface 400 uses a fixed additional buffer of 64 samples on
the playback side only, which is added to the current buffer size. The main advantage is the
ability to use lowest latency at highest CPU loads. Furthermore, the fixed buffer does not add to
the latency jitter (see Tech Info), the subjective timing is extraordinary.
Core Audio's Safety Offset
Under OS X, every audio interface has to use a so called Safety Offset, otherwise Core Audio
won't operate click-free. The Fireface uses a safety offset of 64 samples. This offset is signalled
to the system, and the software can calculate and display the total latency of buffer size plus
AD/DA offset plus safety offset for the current sample rate.

35.3 FireWire Audio

FireWire audio is in several ways different from PCI audio interfaces. First of all, our cards have
a PCI interface which has been developed by RME and optimized for audio. FireWire on the
other hand, uses OHCI-compatible controllers that have not been optimized for audio, no matter
from which manufacturer they are. Our PCI data transmission is per channel, while FireWire is
working interleaved, i.e. it transmits all channels simultaneously. With the Hammerfall drop-outs
thus occur only on the last channels, which is not always noticeable, while a drop-out with Fire-
Wire always concerns all channels and is thus perceived much clearer. Apart from this, RME's
PCI audio cards establish a direct connection with the application under ASIO (Zero CPU load),
which is principally not possible with FireWire, because communication has to be established by
the operating system's FireWire driver. Compared to our PCI cards, the FireWire subsystem
creates an additional CPU load at lower latencies.
One Fireface 400 can achieve a performance similar to a PCI card with an optimal PC. An 'op-
timal' PC has an undisturbed PCI bus. Intel's motherboard D875PBZ e.g., has network, PATA
and SATA connected directly to the chipset. No matter what you do with the computer, FireWire
audio is not being disturbed. The same holds true for the ASUS P4C800, as long as you leave
the additional SATA controller (PCI) unused.
Due to insufficient buffering within FireWire controllers, single
peak loads on the PCI bus can already cause loss of one or more
data packets. This is independent of the manufacturer and no
RME problem. The Fireface 400 features a unique data checking,
detecting errors during transmission via PCI/FireWire and display-
ing them in the Settings dialog. Additionally the Fireface provides
a special mechanism which lets record and playback continue in
spite of drop-outs, and corrects the sample position in real-time.
Detailed information on this topic can be found in the Tech Info
FireWire Audio by RME – Technical Background on our website:
http://www.rme-audio.com/english/techinfo/fwaudio_rme.htm
User's Guide Fireface 400 © RME
85