Missing Metrics - Latency!

[drumphil]

Latency only matters when in relation to something else. Such as in creating music (MIDI) , making a recording,or using video games or showing a movie or video. For straight audio playback on a stereo system (or multi channel) for music only, the overall latency is irrelevant.

Unless you are playing through two devices simultaneously. But you are correct, doesn't matter for simple playback through a single device.

 

[Torin Krell]

Computers with different capabilities (overall power) will vary in the low buffer size they can maintain in a DAW under a heavy load of virtual synths, plugin effects and track count. Under minimal loads however only minor or no differences may indeed be noted. When the DAW's buffer size needs to be increased because a less capable computer (by glitching, freezing etc) indicates that it cannot otherwise keep up, latency of course will increase. Track to track bouncing without track to track latency is possible because of the delay compensation modern DAWs implement. When certain complex plugins - such as those with a significant "look ahead function" create a greater demand for delay compensation this will also be more likely to increase the need to augment the DAWs running buffer size on less capable computer systems. So simply stated more powerful computers will be more able to maintain a DAW's low latency operation under significant loads than less capable computers because smaller buffer sizes can be used without any issues.

 

[drumphil]

Computers with different capabilities (overall power) will vary in the low buffer size they can maintain in a DAW under a heavy load of virtual synths, plugin effects and track count. Under minimal loads however only minor or no differences may indeed be noted. When the DAW's buffer size needs to be increased because a less capable computer (by glitching, freezing etc) indicates that it cannot otherwise keep up, latency of course will increase. Track to track bouncing without track to track latency is possible because of the delay compensation modern DAWs implement. When certain complex plugins - such as those with a significant "look ahead function" create a greater demand for delay compensation this will also be more likely to increase the need to augment the DAWs running buffer size on less capable computer systems. So simply stated more powerful computers will be more able to maintain a DAW's low latency operation under significant loads than less capable computers because smaller buffer sizes can be used without any issues.

Correct, but I'm not talking about measuring that type of performance. I'm just talking about actually knowing what the round trip latency is at a given buffer size with audio interfaces, or the input or output latency from spdif input to analog output, or vice versa, with stand alone DAC/ADC 's.

 

[Torin Krell]

Correct, but I'm not talking about measuring that type of performance. I'm just talking about actually knowing what the round trip latency is at a given buffer size, or the input or output latency from spdif input to analog output, or vice versa, of a DAC.

The latency of a given buffer size on a variety of computers may be similar but will still vary based on the exact hardware, interface, drivers, OS and other software that may be used. However the minimal buffer size that will work smoothly and consistently can be smaller on a more powerful computer system, resulting in lower latency.

 

[drumphil]

However the minimal buffer size that will work smoothly and consistently can be smaller on a more powerful computer system, resulting in lower latency.

What buffer sizes can be sustained on a given computer is the answer to a different question.

 

[nagster]

This is an impulse response measurement of the RME ADI-2 DAC.
The results of 30 coaxial input tests and 30 USB input tests are displayed superimposed.

 

[Jaxx1138]

This is an impulse response measurement of the RME ADI-2 DAC.
The results of 30 coaxial input tests and 30 USB input tests are displayed superimposed.View attachment 530039View attachment 530049

That is the DAC I use. Thanks for the metric.

 

[phofman]

This is an impulse response measurement of the RME ADI-2 DAC.
The results of 30 coaxial input tests and 30 USB input tests are displayed superimposed.

Very nice, thanks. Please do I understand correctly that despite the buffer size set to 64 samples, the roundtrip latency for USB is between 25 to 65 ms?

How was the SPDIF input actually measured? IIUC the signal always went through USB from the measurement computer.

EDIT: I see it's AP software, so maybe the SPDIF measurement went through the AP hardware, not through the RME USB driver as on the screenshot. Thanks

 

[nagster]

The signal to the ADI-2 DAC's coax input was oscillated by the APx555's digital I/O module and output from the unbalanced terminal.
This signal did not pass through the computer.

The signal path to the USB input was APx500 software > RME MADIface USB Driver > onboard USB 2.0 terminal. It was then directly connected to the ADI-2 DAC via a USB cable.
This shows only the forward path, not a round-trip.

 

[phofman]

The signal to the ADI-2 DAC's coax input was oscillated by the APx555's digital I/O module and output from the unbalanced terminal.
This signal did not pass through the computer.

Thanks, that is nicely shown in the minimal latency.

The signal path to the USB input was APx500 software > RME MADIface USB Driver > onboard USB 2.0 terminal. It was then directly connected to the ADI-2 DAC via a USB cable.
This shows only the forward path, not a round-trip.

I wonder how the AP software works via ASIO, as the latency looks way too long and surprisingly varied. It looks as if the playback went through windows mixer, not directly via ASIO.

 

[nagster]

Next, I performed measurements using a different AP (APx525) and a different computer, but the results were basically the same. However, the distribution was between approximately 10ms and 35ms.

On the other hand, changing the volume or muting in the Windows mixer did not change the output of the ADI-2 DAC. The limiter did not activate even with 0dBFS output.

As far as I could tell, when I launched the APx500 software and selected ASIO output, the only way to change the ADI-2 DAC output on the computer was through the APx500 software.
Based on these points, it seems that the Windows mixer is not being used. However, the fluctuations are reproducible.

I don't know anything about the internal workings of the APx500 software. Since it's an APx500 and RME combination, MC_RME might know the truth.


@MC_RME,
Could you please tell us about these fluctuations?

 

[drumphil]

Odd resuts indeed, in terms of unexpectedly high latency and variability.

Perhaps I'm not understanding something here, but how does the AP hardware get accurate information about when the audio was sent by the AP software, when it isn't generating the test signal? Does that information get fed back to the AP via a data link?

 

[phofman]

Perhaps I'm not understanding something here, but how does the AP hardware get accurate information about when the audio was sent by the AP software, when it isn't generating the test signal? Does that information get fed back to the AP via a data link?

My 2 cents the AP measurement of latency via non-AP playback chain (i.e. via some third-party audio interface, using windows audio drivers) is not designed to work correctly and yields irrelevant data. Just for the reason you ask about - the hardware (which measures the latency for the SPDIF generator-ADC case) would have to know somehow (without latency) when software outputs data to the driver buffer. Plus still latency of the whole driver chain would be included.

It looks like it just measures loopback latency out/in in software, where latency of the input capture is included - AP has no practical reason to minimize/keep constant the latency of the data transfer from their HW to the software, plus IIUC it does not use USB audio for data acquisition from their device, but some custom protocol.

IMO that shows that Amir would have to use some other method which is getting quite complicated - IIUC he has some set of measurements pre-configured in his AP software and the whole test runs more or less automatically.

 

[drumphil]

My 2 cents the AP measurement of latency via non-AP playback chain (i.e. via some third-party audio interface, using windows audio drivers) is not designed to work correctly and yields irrelevant data. Just for the reason you ask about - the hardware (which measures the latency for the SPDIF generator-ADC case) would have to know somehow (without latency) when software outputs data to the driver buffer. Plus still latency of the whole driver chain would be included.

It looks like it just measures loopback latency out/in in software, where latency of the input capture is included - AP has no practical reason to minimize/keep constant the latency of the data transfer from their HW to the software, plus IIUC it does not use USB audio for data acquisition from their device, but some custom protocol.

IMO that shows that Amir would have to use some other method which is getting quite complicated - IIUC he has some set of measurements pre-configured in his AP software and the whole test runs more or less automatically.

A simple loopback test would be sufficient for audio interfaces (as opposed to stand alone DAC's where the AP spdif to analog measurement is simple and reliable).

Plug cable from audio interface output to audio interface input, run test, job done.

The round trip is what people doing audio production want to know about an audio interface.

Oblique Audio - RTL Utility

oblique-audio.com

I do understand that this is an extra step, but it is a standard measurement of audio interfaces designed for audio production.

 

[TK_IIVI]

The round trip is what people doing audio production want to know about an audio interface.

Oblique Audio - RTL Utility

oblique-audio.com

I do understand that this is an extra step, but it is a standard measurement of audio interfaces designed for audio production.

But is that what we're talking about? "doing audio production"? Because if it is then using converters made for that purpose is still the way to go, and as I showed earlier there is a latency test floating around of a bunch of the most common devices out there.

I mean, at some point there has to be utility in the testing that's done otherwise it's just a waste of time, and using "consumer" converters for audio production tasks just isn't recommended by virtually anybody who does actual audio production (at least those that do it for a living). It seems to me that this community here would likely mostly not really benefit that much from these figures for consumer devices. I feel like the more I think about this the less of a reward relative to effort I see. Not that I have a personal stake in this...

 

[drumphil]

But is that what we're talking about? "doing audio production"? Because if it is then using converters made for that purpose is still the way to go, and as I showed earlier there is a latency test floating around of a bunch of the most common devices out there.

I mean, at some point there has to be utility in the testing that's done otherwise it's just a waste of time, and using "consumer" converters for audio production tasks just isn't recommended by virtually anybody who does actual audio production (at least those that do it for a living). It seems to me that this community here would likely mostly not really benefit that much from these figures for consumer devices. I feel like the more I think about this the less of a reward relative to effort I see. Not that I have a personal stake in this...

It's not just consumer devices that get reviewed here, and this kind of information expands the range of equipment that can be used in many different situtions, not just whatever market segment the manufacturer intended.

I would hope that Audio Science Review isn't limited to Audiophile Fidelity Curiosity Review.

 

[TK_IIVI]

I understand, but we already have the Gearspace thread with latency information in it for pro devices. So, is that not sufficient if those are the types of devices we'd use anyway for actual audio production.

 

[Ropeburn]

This is an impulse response measurement of the RME ADI-2 DAC.
The results of 30 coaxial input tests and 30 USB input tests are displayed superimposed.View attachment 530039View attachment 530049

The unpredictability of the USB results is a nightmare for recording and realtime processing both. 40ms variance? Ugh. Unusable!

 

[phofman]

The unpredictability of the USB results is a nightmare for recording and realtime processing both. 40ms variance? Ugh. Unusable!

Yes, but those results do not look valid for a USB device directly via ASIO. The core USB layer has its latency, but certainly not tens of ms with that variance. It looks like the measurement method is flawed, IMO the capture path has more or less random latency.

 

[john61ct]

using "consumer" converters for audio production tasks just isn't recommended by virtually anybody who does actual audio production

Please clarify what is meant by "converter" here.

ADC / DACs in general?

Interfaces that connect to PCs or other host computing devices?

Or also including standalone DDCs ?