Missing Metrics - Latency!

[drumphil]

Actually USB3 has no effect on latency compared to USB2, the microframe interval is the same 125us. However, it can deliver 16 times more channels (USB2 allows maximum of 1024 bytes per isochronous packet x 3 transations per microframe, while USB3 allows 1024 bytes per isochronous packet x 16 packets x 3 bursts).

The comparison is intended to be between PCIE devices and USB devices, not USB versions. The figures I have just happen to be for USB3 mode, as tabulated in the link in my 7th post.

As for the rest, I don't think that telling the average reader to get the spec sheets for all the internal components, and infer which filter mode is being used from other information provided, to figure out what the conversion latency of a ADC, DAC or combinded ADC/DAC unit, is really a practically useful approach for most people.

As demonstrated here, if we even if we assume the 1.5ms vs 0.5ms conversion latency with the behringer units to be round trip, not one way, it is still an example of a "free" millisecond of latency performance to be gained, and that is not an insignificant improvement in the usage cases outlined, and is hard to come by through other means.

The rest of the technical discussion, while interesting, is getting a bit far from the points:

Conversion latency can make up a non trivial amount of total system latency. The difference in latency between some converters is also non trivial. This information is useful, particularly to people in music and audio production.

If you're spending money on RME audio interfaces, because you do want the lowest latency possible, knowing that there is potential for 1ms to be gained or lost depending on which DAC/ADC converter racks you choose, is valuable information. A 0.5ms gain would still be valuable. We're not talking about half a percent either way with these differences.

Frequently in live audio there is more than one conversion takes place, and before that there can other instrument latencies, in my case the electronic drum kit. Anything I can do to reduce the total system latency helps.

 

[drumphil]

For recording and layering multitracked music it is quite important.

For playback only it is irrelevant.

Lots of things that don't matter when you're just consuming content, come into play when you're creating it.

 

[Mnyb]

Filter modes ? For ”reasons” many consumer DAC’s lets you pick from a menu of several reconstruction filters for the DAC so now you may have 6 different figures to pick from ?

RME for example has ”SD” versions of their filters in the ADI2-FS series of DAC’s ”Short Delay” the drawback migth include not as perfect filtering and less phase linearity. So you can trade time for some other imperfections in the use cases where it matters.

So unfortunately this would require the review to present latency figures for all filter modes ?

IMO this are inconsequential for normal listening even lips sync or gaming. It may matter for exactly the use cases OP describes playing along with musical instruments to the sound coming out of the system.

Same with some active monitors they have delay too in the DSP crossover that figure is probably larger than the ones in any DAC btw .and some of them also lets you trade time for less perfect performance, for example turning of phase compensation.

I’ve seen latency figures for subwoofers at 8ms ?

I don’t know what the research says about human ability ? When is it a problem ? I suspect using 3 decimals when presenting latency in milliseconds is overkill do you move your head around even when trying to sit still yes you do .

Sound moves at 360 meters per second roughly so you have a millisecond or two in travel time across you desk in the air to your ears .

 

[phofman]

As for the rest, I don't think that telling the average reader to get the spec sheets for all the internal components, and infer which filter mode is being used from other information provided, to figure out what the conversion latency of a ADC, DAC or combinded ADC/DAC unit, is really a practically useful approach for most people.

My point is that measuring the actual latency of the device (and only of the device) is quite difficult, while most interfaces will be below 1ms anyway, not only some special designed ones - that is why I gave the example of a random onboard HDA device. The main difference is in software which everyone will have different. IMO most user computers are not in a state to run at 32 frames buffer reliably, they would experience glitches. Internet is full of long lists for windows tweaks to run at small latency reliably. Many users even go through OS audio mixers which add 10ms at least (typically more). So whether the actual latency of interface is 0.5ms or 1ms makes no big difference if the software stack adds extra 10ms (or easily more).

Yes, it is interesting for audio makers, but IMO no reason to include to the common measurement set for Amir, as for vast majority of devices he measures the exact latency is not important. Also his gear can measure precisely only latency through SPDIF input which is a small subgroup and not very interesting as it does not include the normally needed PC -> SPDIF convertor.

 

[drumphil]

My point is that measuring the actual latency of the device (and only of the device) is quite difficult, while most interfaces will be below 1ms anyway, not only some special designed ones - that is why I gave the example of a random onboard HDA device. The main difference is in software which everyone will have different. IMO most user computers are not in a state to run at 32 frames buffer reliably, they would experience glitches. Internet is full of long lists for windows tweaks to run at small latency reliably. Many users even go through OS audio mixers which add 10ms at least (typically more). So whether the actual latency of interface is 0.5ms or 1ms makes no big difference if the software stack adds extra 10ms (or easily more).

Yes, it is interesting for audio makers, but IMO no reason to include to the common measurement set for Amir, as for vast majority of devices he measures the exact latency is not important. Also his gear can measure precisely only latency through SPDIF input which is a small subgroup and not very interesting as it does not include the normally needed PC -> SPDIF convertor.

You are correct that people who don't care, don't care... People who deal with real time audio requirements would love to have that information available.

Certainly would be nice to have it for devices (SPDIF DAC's) where it just a matter of noting a figure on the screen.

So unfortunately this would require the review to present latency figures for all filter modes ?

Doesn't he usually test the different filter modes anyway? Not much extra work to note a figure in milliseconds.

Anyway, this is up to Amir to decide, as he is the one who would have to do it. I've made my arguments, that's all I can do.

 

[nagster]

I don't see anything wrong with the request for additional measurements.
However, publishing measurement data is neither easy nor casual.
If the measurements are incorrect, it will have a significant impact not only on ASR members, but also on the future of the device manufacturer, its employees, and their families.
I also occasionally post measurement data, but I double-check it multiple times to ensure there are no errors. There is pressure involved.
The impact of the measurement data published by Amirm as an official ASR review must be enormous, and the pressure on him is immeasurable.

In both music production using DAWs and gaming, audio signals pass through a computer.
If non-real-time systems are involved, latency will vary.
Obtaining scientifically valid data would require extensive sampling and statistical processing.
Furthermore, it's uncertain whether the results from Amirm's computer can be applied to other people's computers.

In the case of music production, it's fine as long as it doesn't interfere with performance.
I think it's best to use a proven audio interface. In most cases, analog input is also necessary. There's no reason to force the use of a listening-only USB DAC.

On the other hand, the situation is serious in esports.
Minimize delays as much as possible, whether perceptible or not. A 1-millisecond delay in player input could mean losing $1 million.
Adding a HPA to the onboard analog I/O seems like a safer configuration.

Chord Hugo 2 Review (Portable DAC & HP Amp)

For curiosity: do you know the audio latency of a modern mobo with integrated sound chip? I would not, but I reckon it varies, from card to card. The more processing there is the more delay there is. And as I mentioned before, there are hardware and software buffers deliberately implemented for...

www.audiosciencereview.com

 

[drumphil]

I don't see anything wrong with the request for additional measurements.
However, publishing measurement data is neither easy nor casual.
If the measurements are incorrect, it will have a significant impact not only on ASR members, but also on the future of the device manufacturer, its employees, and their families.
I also occasionally post measurement data, but I double-check it multiple times to ensure there are no errors. There is pressure involved.
The impact of the measurement data published by Amirm as an official ASR review must be enormous, and the pressure on him is immeasurable.

In both music production using DAWs and gaming, audio signals pass through a computer.
If non-real-time systems are involved, latency will vary.
Obtaining scientifically valid data would require extensive sampling and statistical processing.
Furthermore, it's uncertain whether the results from Amirm's computer can be applied to other people's computers.

In the case of music production, it's fine as long as it doesn't interfere with performance.
I think it's best to use a proven audio interface. In most cases, analog input is also necessary. There's no reason to force the use of a listening-only USB DAC.

On the other hand, the situation is serious in esports.
Minimize delays as much as possible, whether perceptible or not. A 1-millisecond delay in player input could mean losing $1 million.
Adding a HPA to the onboard analog I/O seems like a safer configuration.

Chord Hugo 2 Review (Portable DAC & HP Amp)

For curiosity: do you know the audio latency of a modern mobo with integrated sound chip? I would not, but I reckon it varies, from card to card. The more processing there is the more delay there is. And as I mentioned before, there are hardware and software buffers deliberately implemented for...

www.audiosciencereview.com

USB audio interfaces have the same latency at a given ASIO buffer size on any computer. I'm yet to see anyone produce evidence of taking an audio interface from one computer to another and getting a different result, except maybe back in the days of the transition from windows 98 to the NT family of operating systems. Same when moving between different Mac's and Mac OS versions.

Can anyone actually point to differeing results with the same audio interface because of the computer and os version in non ancient computer times?

Standalone DAC/ADC unitns, SPDIF to analog, or vice versa is much simpler, and this information can be read from an Audio Precision analyzer.

 

[john61ct]

untins?

 

[phofman]

USB audio interfaces have the same latency at a given ASIO buffer size on any computer.

For USB the ASIO buffer is only one of the several buffers involved in the USB transmitter chain. So I would not be sure about same latency on any hardware/OS.

But the problem is how to measure the minimal value - one computer setup will be able to handle 32 frames of buffer flawlessly, while another setup will struggle at 128 frames - it all depends on the software + drivers + hardware of the given setup. E.g. I showed my linux desktop can run Intel HDA at 32 frames at 192kHz (i.e. 166us IRQ period => 6k IRQs per second in each direction) - can a different computer running windows with MS Intel HDA drivers do so? Maybe yes, maybe no. If the measurement computer could not and could reach e.g. only 128 frames stable loopback - what would be the measured and officially reported latency?

For SPDIF devices the APx can directly measure latency of the actual device with SPDIF input, because APx knows the latency of its built-in SPDIF transmitter and can subtract that from the loopback. For USB - yes a USB loopback could be measured by analyzing captured OUT/IN USB packets which have timestamps - but I have not seen any software actually doing that.

 

[john61ct]

So, "it's complicated" as is often the case "it depends"

 

[drumphil]

untins?

lol, units!

 

[drumphil]

For USB the ASIO buffer is only one of the several buffers involved in the USB transmitter chain. So I would not be sure about same latency on any hardware/OS.

And yet I can read a review of an audio interface where they measure the analog to analog round trip when using the ASIO driver interface at a variety of buffer sizes, and I can buy the same interface, and plug it to any of the many windows computers systems I have, and I can measure the same analog to analog round trip latency at each buffer size as they achieved in the review.

To allow for the correct alignment of tracks when recording overdubs, the ASIO driver has to report accurately how long it takes for input and output, and the OS is not able to insert itself. ASIO drivers should bypass all other windows systems. Any other buffers imposed by the drivers or hardware have to be factored in by the device manufacturer, or overdubs will be out of allignment. The figures might not be perfectly sample accurate, but they should be pretty damn close.

At least for an interface tested on pc, compared to the same interface on other pc's, and an interface tested on mac, compared to the same interface tested on other mac's.

The underlying hardware can not change this. A computer can either sustain operation at a specific buffer size, or not. The underlying hardware cannot vary the latency at a given buffer size.

* (yes, mac's don't have ASIO drivers, they have their own system, but even then, I've seen no evidence of significant variation with a specific audio interface, between multiple reasonably modern mac os versions, across a variety of apple hardware)

Total round trip times at a given buffer size are easy to measure.

Plug an analog cable from an output back to an input, and run a round trip measuing utility, like the oblique RTL utility.

Oblique Audio - RTL Utility

oblique-audio.com

I don't know if it's perfectly sample accurate, but it is more than close enough for such assessments.

But the problem is how to measure the minimal value - one computer setup will be able to handle 32 frames of buffer flawlessly, while another setup will struggle at 128 frames - it all depends on the software + drivers + hardware of the given setup. E.g. I showed my linux desktop can run Intel HDA at 32 frames at 192kHz (i.e. 166us IRQ period => 6k IRQs per second in each direction) - can a different computer running windows with MS Intel HDA drivers do so? Maybe yes, maybe no. If the measurement computer could not and could reach e.g. only 128 frames stable loopback - what would be the measured and officially reported latency?

That is a different question.

 

[phofman]

, the ASIO driver has to report accurately how long it takes for input and output, and the OS is not able to insert itself. ASIO drivers should bypass all other windows systems. Any other buffers imposed by the drivers or hardware have to be factored in by the device manufacturer, or overdubs will be out of allignment. The figures might not be perfectly sample accurate, but they should be pretty damn close.

The ASIO driver for a USB audio device hands over its data to USB core driver which composes data from all drivers of all devices connected to the USB controller it serves. The ASIO (or linux alsa usb-audio, same thing) buffer is not transmitted by the USB controller right away. The URBs created by the USB client driver (i.e. ASIO USB audio driver, or driver for any other USB device) are submitted to the USB core driver which schedules the URB to a queue of corresponding endpoint and registers that memory part to the DMA controller for DMA transfer to the USB controller, when its time comes.

For linux: e.g. https://github.com/torvalds/linux/blob/master/drivers/usb/core/urb.c#L268-L271:

Drivers should try to keep at least one or two msec of data in the queue; many controllers require that new transfers start at least 1 msec in the future when they are added.

For windows https://learn.microsoft.com/en-us/w...he-starting-usb-frame-number-for-the-transfer:

There is always latency between the time that the client driver submits an URB and the time that the USB driver stack processes the URB. Therefore, the client driver should always specify a start frame that is later than the frame that is current when the driver submits the URB.

So the USB audio-device driver (be it vendor-provided ASIO or standard windows usbaudio2.sys or linux snd-usb-audio or osx usb audio driver) cannot know exactly the latency of the USB stack below. It knows only its own buffer size. Also there is no standard way for a UAC1/UAC2/UAC3 device to report its internal latency to the host via its USB descriptor as no such field is specified in those standards.

 

[drumphil]

The ASIO driver for a USB audio device hands over its data to USB core driver which composes data from all drivers of all devices connected to the USB controller it serves. The ASIO (or linux alsa usb-audio, same thing) buffer is not transmitted by the USB controller right away. The URBs created by the USB client driver (i.e. ASIO USB audio driver, or driver for any other USB device) are submitted to the USB core driver which schedules the URB to a queue of corresponding endpoint and registers that memory part to the DMA controller for DMA transfer to the USB controller, when its time comes.

For linux: e.g. https://github.com/torvalds/linux/blob/master/drivers/usb/core/urb.c#L268-L271:


For windows https://learn.microsoft.com/en-us/w...he-starting-usb-frame-number-for-the-transfer:



So the USB audio-device driver (be it vendor-provided ASIO or standard windows usbaudio2.sys or linux snd-usb-audio or osx usb audio driver) cannot know exactly the latency of the USB stack below. It knows only its own buffer size. Also there is no standard way for a UAC1/UAC2/UAC3 device to report its internal latency to the host via its USB descriptor as no such field is specified in those standards.

So how is it that ASIO drivers are able to report the real input latency and real output latency of an audio interface, consistent from one windows computer to another?

If I take a RME audio interface, be it an internal card, or external USB device, I can play a track in a DAW, record it back onto another track, and have it line up correctly, in a manner that doesn't change from one computer to another.

If i use the oblique RTL utility with my M-Audio Audiophile 2496 card, and measure the round trip (software to analog out, and back through analog input to software again) with a 64 sample ASIO buffer @44.1kHz, it measures 197 samples. The driver reports 199, so the real round trip is withing 2 samples of what the driver reports to the DAW software. This seems to me to be too close to perfect to be by chance.

This figure has remained unchanged regardless of which computer I have the card installed in, or which windows OS version I've been using over the years.

 

[TK_IIVI]

Obtaining scientifically valid data would require extensive sampling and statistical processing.
Furthermore, it's uncertain whether the results from Amirm's computer can be applied to other people's computers.

The data that's the most relevant is probably the relative performance between devices. After all, devices are purchased for a reason, and given a budget people choose between options. So regardless of the absolute value of "Device X" what is of interest is if there's a better device for the same amount of money.

In other words, if a person measures a bunch of interfaces on the same platform (OS etc.) then the isolated parameter is going to be the interfaces, not the platform. Thus we see the difference between interfaces.

Now, obviously, if different devices perform differently depending on for example the OS build then there's a consideration to be had regarding which build to use. In fact, larger tests of hardware for pro audio, like DAWbench, typically involves updating the core system and then running all hardware on that version of the system, every time the test is run. That means that when testing CPUs the system is set up and all CPUs are tested. When a new CPU comes out the system may need to be updated and therefore all CPUs are re-tested along with the new CPU. That means all results are essentially more about the relative performance of those chips on that system.

I think it's near impossible to isolate all parameters without doing a tremendous amount of work, including some serious thinking about how we should evaluate the results considering possibly variable performance depending on the core testing platform, but nevertheless some people might find it useful to get at least relative results to look at.

 

[phofman]

So how is it that ASIO drivers are able to report the real input latency and real output latency of an audio interface, consistent from one windows computer to another?

ASIO drivers are supplied by manufacturers of the actual device, so the device internal latency value/calculation can be hard-coded there. Linux alsa does it for some sound drivers https://github.com/search?q=repo:to...elay+repo:torvalds/linux+path:sound&type=code . Clearly it's crude and unprecise, which is a known issue which seriously affected e.g. Pulseaudio at its beginning when its author heavily relied on correctness of that value in his tickless algorithm.

For USB alsa queries the USB controller driver for current frame number and adds the frames queued for the DMA transfer https://github.com/torvalds/linux/b...7fd5eb738038ddae609d6/sound/usb/pcm.c#L32-L67. ASIO drivers have very likely similar information available from the windows USB-core stack.

Unfortunately ASIO drivers source code is almost never available to check how they do it.

Have you measured precisely to check validity of the reported value?

 

[drumphil]

Have you measured precisely to check validity of the reported value?

Using the oblique RTL test utility.

If it were wrong, my tracks wouldn't line up in DAW software, playing from one track, out and back in through the audio interface and recording on a second track, but they do line up, within a couple of samples.

 

[phofman]

But all the time I was talking about USB devices, while IIUC your tested soundcard is PCI. On PCI the ASIO buffers are directly DMA memory, no extra latencies involved in host software. According to the datasheet the ICE1712 PCI controller in your soundcard has a ping-pong DMA FIFO, I assume i.e. one frame latency. Plus the codecs group delay - likely hard-coded in the driver.

 

[drumphil]

But all the time I was talking about USB devices, while IIUC your tested soundcard is PCI. On PCI the ASIO buffers are directly DMA memory, no extra latencies involved in host software. According to the datasheet the ICE1712 PCI controller in your soundcard has a ping-pong DMA FIFO, I assume i.e. one frame latency. Plus the codecs group delay - likely hard-coded in the driver.

I have never been talking only about USB devices, and the behaviour I note is true for USB and PCI devices.

 

[Jaxx1138]

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.