RME: Latency lowest with FW, USB, or ?

[dancerchris]

Tarekith/Leeds: I'm a little suprised at the continued talk of latency as equivalent to the buffer size setting. Most often I find it best to think of the formula:

Latency_total = 2*buffer_samples+hardware_latency

The only way to find out the value of hardware latency is to do a closed loop recording and look at the offset. (See the driver error compensation lesson in Live's Tutorials). This will give you the total round trip time. The buffer portion of this is often less than half of the total latency. Especially when ASIO4ALL is used. I often can get my buffer setting to a considerably lower value than the native ASIO driver value. However the total latency value is larger after doing the loop test and doing the compensation so I run with the native ASIO driver because it is lower total value. This is because ASIO4ALL is a wrapper program using the existing hardware WDM drivers and wrapping it for use with ASIO. This is inherently innefficient. ASIO4ALL is generally only usefull if the driver is problematic or non-existent. When Live querries ASIO4ALL it can only get information on the ASIO4ALL portion of the wrapper and none of the inherent driver latency with the WDM portion.

As to the original subject of the thread, RME makes great low hardware_latency value sound boxes/cards. The low buffer settings is more a function of the available computers resources and the software being used. Some HOSTS are more effecient than others, e.g. Reaper is more efficient than Live. Different VSTs can be more demanding as well.

For best practice latencies should be mentioned with the given buffer size, the project sampling rate (44.1k, 96k, etc.), and the total loop latency value with loop tested driver error compensation value.

My $0.02

[[nis]]

Don't forget that for softsynth performance (vst) Live has an extra buffer which by default is set to the same as audio, effectively doubling the latency when using vst synth (or FX) plugins - this can be adjusted in the preferences (and probably should be). So your 12ms audio roundtrip is going to be more when using vst virtual synths, even on the lowest 32 sample VST buffer.

Think you got that wrong, either that or Ableton tech support got it wrong when they explained it to me. If the plug in buffer setting is the same as audio it's the same as audio, not doubled. The setting is there to give you the ability to set the plug ins at a lower buffer setting than the audio buffer, or higher I guess if you're wanting to?

No, plugin buffers will always add to the audio buffer. Let's assume you have an audio buffer of 256 samples and the plugin buffer size in the CPU preferences is set to "as audio buffer", then you'll get a total latency of (at least) 512 samples when playing a VST plugin. Some plugins may even introduce more latency, e.g. convolution reverbs, mastering plugins with oversampling algorithms, lookahead functions, etc.

Best,
Nico

[slirak]

No, plugin buffers will always add to the audio buffer. Let's assume you have an audio buffer of 256 samples and the plugin buffer size in the CPU preferences is set to "as audio buffer", then you'll get a total latency of (at least) 512 samples when playing a VST plugin. Some plugins may even introduce more latency, e.g. convolution reverbs, mastering plugins with oversampling algorithms, lookahead functions, etc.

Best,
Nico

Thanks for clearing that up Nico! It did seem to me that Machine's interpretation implied that inserting a plug-in would allow for lower latency than not inserting it, which would of course be a bit weird...

Would you mind commenting on dancerchris' post too? Or rather, about the proper use of driver error compensation. It seems to me that this setting is often misunderstood. I actually think misuse of it is the reason for quite a few timing issues.

[[nis]]

Thanks for clearing that up Nico! It did seem to me that Machine's interpretation implied that inserting a plug-in would allow for lower latency than not inserting it, which would of course be a bit weird...

Would you mind commenting on dancerchris' post too? Or rather, about the proper use of driver error compensation. It seems to me that this setting is often misunderstood. I actually think misuse of it is the reason for quite a few timing issues.

Yes, this is indeed often misunderstood. A common mistake is that people think they can somehow "get rid" of an audio interface's latency by applying a negative DEC value until the "overall latency" shows 0 ms. THIS IS WRONG AND WILL LEAD TO AN INCORRECT RECORDING BEHAVIOUR / LATENCY COMPENSATION!

The driver error compensation (DEC) has the following purpose:

When recording audio, where the signal is monitored externally (e.g. through an external mixing desk or a soundcard's "direct monitoring" signal path), you should set a track's MONITOR switch to "OFF". If you do this, Live will automatically remove the input latency from the recorded audio file, so that a playback of the recorded clip would be timing-wise identical with the monitored signal. In contrary, when having the MONITOR switch set to AUTO or IN, it assumes that you monitor your signal through Live (i.e. the monitored signal is delayed), so it doesn't remove anything from the recording. Live basically always records what you hear, depending on how your signal is monitored. Anyway, the DEC is only relevant for externally monitored recordings (MONITOR switch = OFF).

To find out how high the actual latency is, Live queries the audio interface driver for its input and output latencies. The driver calculates them, reports them to Live and Live displays the results in the audio preference pane (i.e. "input latency", "output latency" and the overall/roundtrip latency). The "input latency" is what Live removes from externally monitored recordings.

Now, the problem is that many audio drivers cannot calculate these latency values 100% accurately, because they might not be able to detect USB / Firewire latencies, hardware safety buffers, etc. That's why it makes sense to manually measure the actual latency with the driver error compensation lesson which you can find in Live's help/lessons view.

What does it do? The DEC lesson comes with a pre-configured Live set, which sends out a click sound and re-records it into another track (you need to connect a cable from your audio output back to the input). Note that the MONITOR switch on track 2 is set to OFF. If you re-record the click sound, Live will automatically remove the input latency, so in a perfect world it should already line-up with the first beat. If it doesn't, then it means that there's an error in the driver's latency calculation. You can now correct this by typing the measured driver error into the appropriate field in Live's audio preferences pane. If you repeat the same test again, the click sound should now line up with the first beat.

RME interfaces are usually 99.9% exact, so you can leave the DEC at 0 ms.

Note: when running the DEC lesson, I'd recommend to temporarily deactivate the "create fades on clip edges" option in the record/warp/launch preferences, because the safety fade would be visible in the re-recorded clip.

Hope this helps.

Best,
Nico

[slirak]

Thanks for clearing that up Nico! It did seem to me that Machine's interpretation implied that inserting a plug-in would allow for lower latency than not inserting it, which would of course be a bit weird...

Would you mind commenting on dancerchris' post too? Or rather, about the proper use of driver error compensation. It seems to me that this setting is often misunderstood. I actually think misuse of it is the reason for quite a few timing issues.

Yes, this is indeed often misunderstood. A common mistake is that people think they can somehow "get rid" of an audio interface's latency by applying a negative DEC value until the "overall latency" shows 0 ms. THIS IS WRONG AND WILL LEAD TO AN INCORRECT RECORDING BEHAVIOUR / LATENCY COMPENSATION!

The driver error compensation (DEC) has the following purpose:

When recording audio, where the signal is monitored externally (e.g. through an external mixing desk or a soundcard's "direct monitoring" signal path), you should set a track's MONITOR switch to "OFF". If you do this, Live will automatically remove the input latency from the recorded audio file, so that a playback of the recorded clip would be timing-wise identical with the monitored signal. In contrary, when having the MONITOR switch set to AUTO or IN, it assumes that you monitor your signal through Live (i.e. the monitored signal is delayed), so it doesn't remove anything from the recording. Live basically always records what you hear, depending on how your signal is monitored. Anyway, the DEC is only relevant for externally monitored recordings (MONITOR switch = OFF).

To find out how high the actual latency is, Live queries the audio interface driver for its input and output latencies. The driver calculates them, reports them to Live and Live displays the results in the audio preference pane (i.e. "input latency", "output latency" and the overall/roundtrip latency). The "input latency" is what Live removes from externally monitored recordings.

Now, the problem is that many audio drivers cannot calculate these latency values 100% accurately, because they might not be able to detect USB / Firewire latencies, hardware safety buffers, etc. That's why it makes sense to manually measure the actual latency with the driver error compensation lesson which you can find in Live's help/lessons view.

What does it do? The DEC lesson comes with a pre-configured Live set, which sends out a click sound and re-records it into another track (you need to connect a cable from your audio output back to the input). Note that the MONITOR switch on track 2 is set to OFF. If you re-record the click sound, Live will automatically remove the input latency, so in a perfect world it should already line-up with the first beat. If it doesn't, then it means that there's an error in the driver's latency calculation. You can now correct this by typing the measured driver error into the appropriate field in Live's audio preferences pane. If you repeat the same test again, the click sound should now line up with the first beat.

RME interfaces are usually 99.9% exact, so you can leave the DEC at 0 ms.

Note: when running the DEC lesson, I'd recommend to temporarily deactivate the "create fades on clip edges" option in the record/warp/launch preferences, because the safety fade would be visible in the re-recorded clip.

Hope this helps.

Best,
Nico

Thanks Nico, this should really be a sticky!
I've talked to several people who think they can/shall use a negative DEC value to achieve what they believe is zero latency.
Some of them are very stubborn in that belief...

[nowtime]

@ Nico: I'm a little confused. I often have my direct monitored instrument tracks set to Auto and it records perfectly.

[dancerchris]

It's important to realize what the DEC is really compensating for: Actual hardware latency vs. calculated. As Nico points out the driver "attempts" to calculate the latency, but can do so only approximately. (Apparently RME ASIO drivers are good at this.)

Therefore I would say that the DEC value is also good for understanding the real true latency of your system, as measured, not calculated.

This is important because there is a big camp that thinks ASIO4ALL does this great job on higher end gear, but when the DEC is measured properly the overall latency with ASIO4ALL will almost always be higher than the native ASIO driver. Most people just look at the buffer size and that's all they think about in terms of overall performance. WRONG!!!!

Again this is my $0.02.

[monobeach]

Thanks Nico, this should really be a sticky!
I've talked to several people who think they can/shall use a negative DEC value to achieve what they believe is zero latency.
Some of them are very stubborn in that belief...

+ 1