• Registered: 2009-07-23
  • Posts: 19

Topic: Reducing FF800 latency vs. using PCIe based solution

Hi,

I'm not sure what latency I have with FF800 now, but it is at least the buffer size (times two) and the latency caused by FireWire (times two) and the latency of the converters (and there are two converters).

To reduce the latency, I'm considering getting another (PCIe based) system, with approx. the same specs as FF800. Which RME system would that be?

The other option is to use the converters in FF800, at least for now, and connect the FF800 to the Mac via a PCIe cards, using adat cables.

Can anyone tell me how low total roundtrip latency I would get then, if I were to use one of RMEs PCIe cards? I assume it would be a lot lower than going through FireWire, since I would bypass the whole FireWire latency, and of course because if the adat solution adds some latency, it should be very low, since it doesn't involve any extra DA or AD conversion.

  • Registered: 2009-07-23
  • Posts: 19

Re: Reducing FF800 latency vs. using PCIe based solution

I know about at least two studios which need to know this before they buy new new I/O gear.... anyone?

Thanks.

  • From: Germany
  • Registered: 2007-04-10
  • Posts: 9,776

Re: Reducing FF800 latency vs. using PCIe based solution

Firewire as such (i.e. as a data transfer protocol) does not introduce significant latency. Buffer size and conversion latency affect PCI/e systems also. Therefore, the difference will not likely be huge on a good system.

Regards
Daniel Fuchs
RME

Regards
Daniel Fuchs
RME

RME Support's Website

  • Knut
  • Knut
  • DAW Mastermind
  • Offline
  • Registered: 2007-04-06
  • Posts: 1,618

Re: Reducing FF800 latency vs. using PCIe based solution

To reduce the latency, I'm considering getting another (PCIe based) system, with approx. the same specs as FF800. Which RME system would that be?

There is no RME PCIe counterpart to the Fireface. The Multiface II comes close but provides only one ADAT I/O and no MicPres. A HDSPe MADI card allows a modular system with several different I/O boxes (Analog, ADAT, AES/EBU plus MicPres). Such a system provides a full flexible I/O setup with endless options, but would be also more expensive.

To measure the real latency of an audio system use this little tool from CEntrance (freeware). Just build a loop on the digital or analog I/Os and start it.

best regards
Knut

  • Registered: 2009-07-23
  • Posts: 19

Re: Reducing FF800 latency vs. using PCIe based solution

RME Support wrote:

Firewire as such (i.e. as a data transfer protocol) does not introduce significant latency. Buffer size and conversion latency affect PCI/e systems also. Therefore, the difference will not likely be huge on a good system.

Regards
Daniel Fuchs
RME

Thanks.

The latency roundtrip in FF800 is 6.1 ms, which seems high compared with PCIe based systems (eg. Symphony apparently has between 31 - 3.4 ms).

I would assume that the reason was FireWire, but it seems I'm wrong....

Anyway: what's the lowest roundtrip latency one can get with an RME solution (on a fast Mac @ 44.1 khz)?

  • Registered: 2009-07-23
  • Posts: 19

Re: Reducing FF800 latency vs. using PCIe based solution

Admin Knut wrote:

To measure the real latency of an audio system use this little tool from CEntrance (freeware). Just build a loop on the digital or analog I/Os and start it.

best regards
Knut

Is there a Mac equivalent?

Thanks.

  • Jeff
  • Jeff
  • Moderator
  • Offline
  • From: USA
  • Registered: 2007-05-21
  • Posts: 4,665

Re: Reducing FF800 latency vs. using PCIe based solution

latency wrote:

The latency roundtrip in FF800 is 6.1 ms, which seems high compared with PCIe based systems (eg. Symphony apparently has between 31 - 3.4 ms).

I would assume that the reason was FireWire, but it seems I'm wrong....

Anyway: what's the lowest roundtrip latency one can get with an RME solution (on a fast Mac @ 44.1 khz)?

This review from Tape Op has some measurements of the Multiface system.

Using the Multiface II and HDSPe PCI combination, with ADM enabled in Cubase 4.1 on Win XP, I measured 1.76 ms of latency for roundtrip analog-digital-analog at 44.1 kHz. Considering sound travels at about 1 ft/ms, that's equivalent to placing your ear less than 2 ft from the sound source; for many instruments, you'd hear the close-mic'ed sound in your headphones before you'd hear the natural soundwaves. Using software monitoring (through the host application) instead of ADM, I measured 5.4 ms roundtrip latency at 44.1 kHz with a 64-word buffer size, the smallest I could go without dropouts (for a 24-track project) in Cubase. Cubase reported latency for an inserted external effect as 0.36 ms. In Cubase 4.1 on Mac OS X, roundtrip latency was 6.84 ms at 44.1 kHz with a 64-word buffer, and insert delay was 1.09 ms. At 96 kHz, latency dropped to 3.52 ms. In Logic 8 with the I/O Safety Buffer disabled, a 32-word buffer at 44.1 kHz yielded 3.9 ms; contrast this to 3.36 ms for Apogee Symphony at the same settings.

Regards,
Jeff Petersen
Synthax Inc.

Jeff's Website

  • Knut
  • Knut
  • DAW Mastermind
  • Offline
  • Registered: 2007-04-06
  • Posts: 1,618

Re: Reducing FF800 latency vs. using PCIe based solution

thanks Jeff. In the same test he wrote:

As a matter of comparison, I measured roundtrip analog-digital-analog latency with ADM enabled, AD?16X to ADI?648 to HDSPe MADI back to ADI?648 to DA?16X: 1.68 ms at 44.1 kHz. Adding the DMX?R100 console to the loop before the HDSPe MADI, the total delay increased to 2.24 ms.

best regards
Knut

  • Registered: 2009-07-23
  • Posts: 19

Re: Reducing FF800 latency vs. using PCIe based solution

Thanks...


Using the Multiface II and HDSPe PCI combination, with ADM enabled in Cubase 4.1 on Win XP, I measured 1.76 ms of latency for roundtrip analog-digital-analog at 44.1 kHz.

That sounds good, but what's "ADM" (I'm using Logic/Mac...)?


In Logic 8 with the I/O Safety Buffer disabled, a 32-word buffer at 44.1 kHz yielded 3.9 ms; contrast this to 3.36 ms for Apogee Symphony at the same settings.

So... this is with Software Monitoring on - right?

AD?16X to ADI?648 to HDSPe MADI back to ADI?648 to DA?16X

What's the minimum setup needed to get this latency? Is ADI-648 needed?

Thanks again...

  • Knut
  • Knut
  • DAW Mastermind
  • Offline
  • Registered: 2007-04-06
  • Posts: 1,618

Re: Reducing FF800 latency vs. using PCIe based solution

That sounds good, but what's "ADM" (I'm using Logic/Mac...)?

ADM = ASIO direct Monitoring. With ASIO Direct Monitoring (since ASIO 2.0), Steinberg has not only introduced ZLM to ASIO, but also extended it substantially. ADM also allows for monitoring the input signal via the hardware in real-time. Over and above that, ADM supports panorama, volume and routing, which requires a mixer (i.e. DSP functionality) in the hardware though. Thus it is possible to copy a routing through a software mixer in the hardware in real-time, so that the sound difference between playback and monitoring is very small.

What's the minimum setup needed to get this latency? Is ADI-648 needed?

You need at least a HDSPe MADI card and an external MADI I/O interface. The PCI express card provides 128 channels (64 Ins + 64 Outs). With the ADI-648 all 128 channels will be converted to ADAT channels (44.1 or 48 kHz). With the ADI-6432 all 128 MADI cannels will be converted to AES/EBU channels (32 stereo I/Os). With ADI-8 QSM, M-16 and M-32 RME offers high-end analog converters. With the Micstasy M it?s possible to connect a high-end MicPre/AD converter to a MADI I/O.

All interfaces with MADI I/O could be added to a chain (Example: 2 x Micstasy M, 4 x ADI-8 QSM). 

Here is an example for an 128 channel ADAT based system with the ADI-648.

best regards
Knut

  • Registered: 2009-07-23
  • Posts: 19

Re: Reducing FF800 latency vs. using PCIe based solution

Thanks....
Are there no combined solutions - eg. with 8 analog in/out plus S/PDIF and one or two stereo AES/EBU connectors?
Is the latency much higher with a non-MADI PCIe card and a breakout box with inputs and outputs?
Could eg. a FF800 be used as an interface (with the HDSPe MADI card) through it's adat connectors?

From what you write, my initial impression is that for someone who basically needs 8 ins/outs and some digital interfacing, he would have to buy both a PCIe card,  an ADI-648 or ADI-6432 and then some kind of AD/DA converters.

Due to the popularity of FF800 and Apogee Ensemble, I'd think that there's a big market for low-latency solutions based on two hardware units only (PCIe + converters), but I could be wrong. I'll take another look on your product pages... I'm very curious about what the minimum cost for a small system with low latency would be.

  • Knut
  • Knut
  • DAW Mastermind
  • Offline
  • Registered: 2007-04-06
  • Posts: 1,618

Re: Reducing FF800 latency vs. using PCIe based solution

Are there no combined solutions - eg. with 8 analog in/out plus S/PDIF and one or two stereo AES/EBU connectors?

There are 3 Fireface models and the Multiface II.

Is the latency much higher with a non-MADI PCIe card and a breakout box with inputs and outputs?

The latency differs between PCI express and FireWire. All RME PCI express cards offers the same latency (HDSPe MADI, AIO, RayDAT or the Multiface/DIGIface PCI express cards). External interfaces connected to these cards can introduce a different latency to the whole system. The new RME USB technology provides also a latency, which could reach as low as PCI express solutions (32 or 64 samples on Mac OS X).

Could eg. a FF800 be used as an interface (with the HDSPe MADI card) through it's adat connectors?

No. This would need the ADI-648 with eight ADAT I/Os. The Fireface offers no MADI I/O and can not be direct connected to the HDSPe MADI.

From what you write, my initial impression is that for someone who basically needs 8 ins/outs and some digital interfacing, he would have to buy both a PCIe card, an ADI-648 or ADI-6432 and then some kind of AD/DA converters.

Yes ... or a Fireface, Multiface II or a HDSPe RayDAT with several AD/DA converters. It seems to me the best solution for your needs is the new Fireface UC with 8 x Analog, 1 x ADAT and 1 x SPDIF (or AES/EBU). You can expect on a Mac a latency from 64 - 128 samples, maybe 32 with a low track and effect count for usual projects.

best regards
Knut

  • Registered: 2009-07-23
  • Posts: 19

Re: Reducing FF800 latency vs. using PCIe based solution

Admin Knut wrote:

You can expect on a Mac a latency from 64 - 128 samples, maybe 32 with a low track and effect count for usual projects.

Latency from 64-128 samples.... total recording roundtrip? At 44.1? That would be less than 1.5 milliseconds... Or do you mean that one could expect to be able to use 64-128 buffer setting (in which case one would have to double that number + add latency from the driver, converters etc...).

  • Registered: 2008-01-01
  • Posts: 3,025

Re: Reducing FF800 latency vs. using PCIe based solution

I will post comparisons of the FF UC, FF 400 and HDSPe + MF2's in/out/roundtrip latencies later.  Most likely the FF 800's latencies are around the values of the FF 400 ones except for the different converters being used!?

  • Registered: 2009-07-23
  • Posts: 19

Re: Reducing FF800 latency vs. using PCIe based solution

Most likely the FF 800's latencies are around the values of the FF 400 ones except for the different converters being used!?

That makes sense to me. To have an inexpensive USB based interface with total roundtrip latencies below Apogee Symphony and other PCIe based systems would would have been great - but is it even technically possible?

Maybe Admin Knut was talking about total latency when software monitoring was disabled?

  • Registered: 2009-07-23
  • Posts: 19

Re: Reducing FF800 latency vs. using PCIe based solution

A few more questions...

What is the lowest recording roundtrip latency that can be seen with any RME setup on OS X, using the 32 buffer?


I found that Logic now reports a roundtrip latency of 4.6 ms @ 44.1 instead of the usual 6.1 ms (I still use FF800) is this due to the new drivers I installed, or has something changed in CoreAudio or Logic?

Will I get lower latency with the FF800 if I use a FF800 cables instead of a FF400 cable?

I contacted my dealer due to noise problems when using the 32 buffer @ 96 kHz... The dealer should call be back (never did), but didn't seem to have much knowledge about this - and now I actually do need to use the setup (32 samples/96kHz). Has anything been improved re. real time roundtrip monitoring @ 96 kHz over the last year?

Why am I called an "Adat user"????  smile I'm not!

  • Registered: 2007-05-09
  • Posts: 174

Re: Reducing FF800 latency vs. using PCIe based solution

Are we chasing something possible here?  In a situation where zero-latency monitoring is really required, isn't 2ms as bad as 5ms?  True zero is achieved easily by analogue loop-back.  Adding this facility with an external mixer isn't expensive, and needn't comprimise the digital recording path and quality.

  • Registered: 2009-07-23
  • Posts: 19

Re: Reducing FF800 latency vs. using PCIe based solution

No, there's a major difference between 2 ms and 5 ms in my ears. Remember that the so called 'no latency' digital systems don't have no latency either. My Pro Tools HD system had 2.4 milliseconds latency.

  • Registered: 2009-07-23
  • Posts: 19

Re: Reducing FF800 latency vs. using PCIe based solution

Bumping my own question here:
Will I get lower latency with the FF800 if I use a FF800 cables instead of a FF400 cable?

And: What's the lowest possible roundtrip latency under OS X for the new FF UFX interface?