Archive for the ‘Input Lag’ Category

A Cheap & Easy Method for Measuring Optical S/PDIF Audio DAC Latency

Tuesday, June 22nd, 2021

In a previous post, I described a method of measuring HDMI audio DAC latency using a computer’s sound card and a Wii U. This post describes a similar method for measuring optical S/PDIF audio DAC latency using a cheap and widely available USB audio DAC as a signal generator. I strongly recommend you give my previous post a read before reading this one to give some context for this approach.

Finding a Signal Generator

Because my Wii U test method resulted in such consistent results, I hypothesized that there might be an integrated circuit out there that would output optical S/PDIF and analog audio at the exact same time. If this was the case, it could act as a signal generator for measuring optical audio DAC latency in the same as the Wii U can be used for HDMI audio.

After some quick shopping, I decided to settle on the LiNKFOR USB DAC Audio Converter which can be purchased for only $22 USD. I found it was available on Amazon (as well as Amazon.ca), AliExpress, and various marketplace sellers.

This USB audio DAC uses the Cmedia CM108B, which is able to output synchronized audio to analog RCA, analog headphone, RCA S/PDIF, and optical S/PDIF at the same time.

LiNKFOR USB DAC Audio Converter ‎ULKDAC070 with Cmedia CM108B

Verifying Output Synchronization

I wanted to be sure that this audio DAC did, in fact, output audio at exactly the same time through the analog outputs and the optical S/PDIF output. To test this, converted the digital optical signal into a digital voltage signal that I could compare more easily with the analog voltage signal of the RCA/headphone output.

I found the EAPLRAA4 Fiber Optic Receiver, which would make this conversion from optical to voltage with a delay of only 120 nanoseconds in a worst case. The datasheet for this receiver came with a “General application circuit”, which made wiring it up extremely easy:

EAPLRAA4 with 3V general application circuit

Now that I can represent the optical signal as voltage, I was able to simply wire it up to my 192 kHz sound card to use as a sort of makeshift oscilloscope. 192 kHz is not a high enough frequency to capture the digital S/PDIF signal in detail, but enough to get a gist of when a change has happened. In the future, I may repeat this test with a proper mixed signal oscilloscope or logic analyzer, but for now I feel these tests clearly show the accuracy of this test method.

Here’s what it looked like at different zoom levels when I played a 4800 Hz tone that turned on and off through foobar2000 in WASAPI exclusive mode:

Although I don’t have enough detail to decode the S/PDIF signal, there seems to be enough detail to show clearly that the different outputs are very closely synchronized by this Cmedia chip, making it ideal for this latency measurement method.

Testing Optical S/PDIF DAC Latency

The test process and hardware for measuring optical S/PDIF DAC latency is virtually identical to the process used for measuring HDMI audio DAC latency with a Wii U, so I will not reiterate any of those details in this post. The only differences are:

  • The optical output of the LiNKFOR USB DAC is used instead of the HDMI output of the Wii U
  • The RCA or headphone output of the LiNKFOR USB DAC is used instead of the analog RCA output of the Wii U
  • The LiNKFOR USB DAC must be connected to a computer. Simply play any audio file you want with the LiNKFOR USB DAC as your output device. (Note: On Windows, it seems like the USB audio device, called “Speakers”, is disabled by default when you plug it in. Simply enable it in your sound settings to use this as your output device.)

During these tests I discovered that there was one quirk with the LiNKFOR USB DAC: the analog audio output seems to be inverted compared to the source and optical audio output. This is not a problem, but is something to be aware of if you are using this method for measuring latency.

Results

I only tested a couple of receivers that I have on hand and included existing latency measurements using my Wii U method:

DeviceSignalSettingAudio Latency
Marantz NR17111080p 60Hz 2.0 StereoDirect6.0ms
Marantz NR17111080p 60Hz 2.0 StereoStereo6.0ms
Marantz NR17111080p 60Hz 5.1 SurroundDirect6.2ms
Marantz NR17111080p 60Hz 5.1 SurroundMulti Ch6.2ms
Marantz NR1711Analog RCA StereoDirect0.0ms
Marantz NR1711Analog RCA StereoStereo0.0ms
Marantz NR1711Optical S/PDIFDirect4.9ms
Marantz NR1711Optical S/PDIFStereo7.9ms
Sony STR-DH5401080p 60Hz 2.0 StereoPure Direct56.5ms
Sony STR-DH5401080p 60Hz 5.1 SurroundPure Direct13.1ms
Sony STR-DH540Analog RCA StereoPure Direct13.0ms
Sony STR-DH540Optical S/PDIFPure Direct55.8ms

Limitations

The Cmedia CM108B is only capable of outputting 44.1 kHz and 48 kHz 16-bit PCM audio over optical S/PDIF. Although many other formats may be transmitted over an optical cable, this format is common and valuable to test. Please let me know if you have any recommendations for other widely available optical audio DACs that would be better suited as a signal generator!

How to Measure HDMI Audio Latency Using a Wii U

Wednesday, May 12th, 2021
Using a Nintendo Wii U to measure HDMI audio latency
Using a Nintendo Wii U to measure HDMI audio latency

Over the past few years it has become easier to find resources that report video input lag. But I have yet to find a good resource for audio delay introduced by receivers, TVs, sound bars, or other HDMI audio DACs. This article outlines a method of testing this delay, called latency or “input lag”, that I have found to be surprisingly precise and easy.

Before I developed this method, I had used the Xbox 360 Rock Band Wireless Fender Stratocaster. Because of the Xbox 360’s HDMI and analog RCA output, I was able to confirm the accuracy of this tool by testing it on an old CRT TV which is known to have virtually zero video and audio latency. I compared the Xbox 360 version to the Xbox One Rock Band 4, but found that the Xbox One version added around 80ms to its reported video and audio latency. It is worth noting that the audio latency reported by these tools does not seem to be extremely consistent. I found I would get results that would vary by 5 or 10 milliseconds with Rock Band 4. It became clear that a new test method was needed that was both consistent and easy for others to reproduce.

Using an Audio Card as a Data Logger

The left and right channels of a computer audio card’s “Line In” are synchronized using a very precise clock. This makes an audio card or audio interface an ideal choice for recording and comparing the offset between two audio sources. Simply wire one source to the left channel and another source to the right channel. Here is a recording of an analog audio signal being split into two and then recorded as the left and right channel of a Line In:

It’s easy to see that there is no delay to either the left or right channels when they are given the same input signal. This precision seems like a good improvement from the inconsistencies I found when using the Rock Band Wireless Fender Stratocaster.

As my audio card I used a USB audio interface that has a separate 1/4″ audio input for each channel as well as gain knobs that let me easily get the two signals at similar levels. So long as you wire it up right, any computer’s audio input should work equally well for this sort of test.

Using the Nintendo Wii U as an Audio Signal Generator

Now that we can record two audio signals and compare them for a delay, we need a way of generating an HDMI audio signal and a lag-free analog audio signal at the same time. I was happy to find that the Nintendo Wii U actually has an option to output audio via HDMI and RCA analog concurrently.

The engineers who worked on the Wii U seem to have done a very good job of synchronizing these two audio output streams, from what I can tell. At the very least, the synchronization between the Wii U’s HDMI audio and RCA analog audio seems to be very consistent, varying by less than half of a millisecond between boot cycles, which makes it ideal for testing audio latency that is introduced by an HDMI audio DAC found in a receiver or TV. I also found the results to be consistent with those from Rock Band for Xbox 360 which I had previously confirmed to be fairly accurate based on my tests with a CRT TV.

One last point for reference: according to my Elgato capture card, it seems that the Wii U outputs 16 bit 48kHz audio alongside 1920×1080 59.94 Hz video. I’m not sure what the refresh rate of the European version of the Wii U is, but I don’t see this affecting many HDMI decoder chips.

Results

To generate an easy-to-analyze audio signal, I simply moved the Wii U game icon list onto the TV screen and used a pro controller to page back and forth between pages of games. This produced high frequency tick sounds that are easy to identify when viewing the waveform. Here is a sample of results from my tests:

BenQ ZOWIE RL2460 Headphone Port: 184/192,000 = 1.0ms
BenQ ZOWIE RL2460 Headphone Port: 184/192,000 = 1.0ms
Video Input Lag Equivalent: 1.0 + 8.3 = 9.3ms*
Sharp Roku TV 7209X Speakers: 9,678/192,000 = 50.4ms
Sharp Roku TV 7209X Speakers: 9,678/192,000 = 50.4ms
Video Input Lag Equivalent: 50.4 + 8.3 = 58.7ms*
Onkyo TX-NR585, Pure Direct, stereo HDMI signal: 2,108/192,000 = 11.0ms
Onkyo TX-NR585, Pure Direct, stereo HDMI signal: 2,108/192,000 = 11.0ms
Video Input Lag Equivalent: 11.0 + 8.3 = 19.3ms*

* 60Hz video input lag includes an additional 8.3ms to account for the average transmission time of individual pixels from the start of a frame. This value should be used when comparing audio latency to video input lag.

Test Method Limitations

It should be clear that there are some limitations to this test because the Wii U can only output up to a 1080p 60Hz video signal with either mono, stereo, or 5.1 surround sound. This means that it can not be used to test the audio latency of a packet-based 120Hz 4K HDMI 2.1 signal, for example.

Although this test method seems to be very precise, there is question as to how accurate it is. The spread of test results, including a 1.0ms latency demonstrated by the BenQ ZOWIE monitor’s headphone port, and consistency with the Xbox 360 Rock Band test suggest that these numbers are likely spot-on.

Testing Hardware

Some HDMI audio DACs may need different cables or equipment to test. For example, you will need a microphone to test speakers. Here is a picture of some of the equipment I have used:

Various cables that can be useful when measuring audio latency
Various cables that can be useful when measuring audio latency
Cables for testing using a basic onboard sound card's Line In
Cables for testing using a basic onboard sound card’s Line In

Won’t my 150W Receiver Speaker Output Damage my Sound Card?

If you are connecting your receiver directly to your sound card, you should make sure to use the Line In and not your Microphone input. The reason is because a typical Line In has a relatively high impedance compared to a Mic input. A higher impedance will reduce the current that flows through your sound card. While speakers are typically 6Ω or 8Ω, a sound card’s Line In is typically between 1,000Ω and 20,000Ω. This means that the current flowing through your sound card will be relatively low, even though your receiver is capable of delivering a much higher current to low impedance speakers.

Comparison of current for different impedance at the same voltage. Screenshots taken from Electric Calcs.
Comparison of current for different impedance at the same voltage. Screenshots taken from Electric Calcs.

The volume of the receiver directly controls the voltage output to your speakers and attaching a high voltage to your sound card could damage your sound card. The volume of your receiver should be set low and slowly increased until it matches the line output of the Wii U. All receivers should be able to operate in very low voltage ranges, much lower than the line-level voltage that your sound card is expecting. Only when the volume is set high will it begin to exceed line-level voltage.

I will be honest that I do not fully grasp the breadth of issues that mixing grounds and ground offsets can cause. If you want to be extra safe, you can always use a passive microphone held to a speaker or a ground loop isolator on your device’s output before mixing it with the Wii U’s ground.

Notes for Testing Receivers

Receivers have a lot of settings and each of these settings can impact audio latency. Here are some notes you should keep in mind when testing audio latency of a receiver:

  • Receivers can often have drastically different latency based on the input signal. It’s a good idea to test different input signals such as 2.0 stereo and 5.1 surround over HDMI.
    • Both a Yamaha and Sony receiver that I tested had over 40ms longer audio latency when processing an HDMI stereo signal compared to an HDMI surround sound signal.
  • A receiver’s “Speaker Distance” setting affects audio latency. Speakers that are a closer distance will have a delay applied to them to make all speakers’ sounds reach the listener at the same moment. When testing, it’s important to set all of the speaker distances to be equal so no delay will be applied to any of the speakers.
    • Automatic speaker calibration such as Audyssey or Accueq will adjust speaker distances, so you should expect this to add a delay to some or all speakers.
  • Equalizers, such as those that are activated by speaker calibration like Audyssey or Accueq, may introduce an additional audio delay. The “Direct” sound mode can be used to disable equalizers.
  • When no equalizer is active, the “Direct” sound mode often does not reduce or increase audio latency for an HDMI signal but often does reduce audio latency for an analog signal. It’s a good idea to test different sound modes to see which affect latency.
    • In my initial tests, only one of six different brands had reduced audio latency in Direct mode with an HDMI signal. Conversely, four out of these six had reduced audio latency in Direct mode for an analog signal.
  • A receiver’s “auto lip sync” feature enables communication with a TV over ARC or eARC to add a delay to audio to match your TV’s video latency. Most receivers also have a manual audio delay setting for lip sync. The manual setting should be set to zero when testing and the auto lip sync setting should be turned off when testing if you have the receiver connected to a TV that may be communicating it’s auto lip sync delay.
  • Most receivers will have a different latency for an analog signal compared to an HDMI signal, so testing with an analog signal (no Wii U required) can be useful if you ever plan to plug in an analog source to your receiver.

HDMI Audio Latency List

Here’s a selection of the HDMI audio latency tests I have done to date using this Wii U testing method:

Monitors

DeviceSignalSettingOutputAudio LatencyVideo Input Lag Equivalent*
BenQ ZOWIE RL24601080p 60Hz 2.0 StereoN/AHeadphones1.0ms9.3ms
LG 27UD59P1080p 60Hz 2.0 StereoN/AHeadphones1.3ms9.6ms

TVs

DeviceSignalSettingOutputAudio LatencyVideo Input Lag Equivalent*
Sharp Roku TV 7209X1080p 60Hz 2.0 StereoGame ModeSpeakers50.4ms58.7ms
Sony Bravia X800H1080p 60Hz 2.0 StereoGameSpeakers96.2ms104.5ms
Sony Bravia X800H1080p 60Hz 2.0 StereoGameHeadphones68.1ms76.4ms
Sony Bravia X800H + MYPIN Audio Converter PC0003231080p 60Hz 2.0 StereoGameOptical + RCA69.2ms77.5ms
Sony Bravia X800H + SHARC eARC Audio Converter1080p 60Hz 2.0 StereoGame w/ ARC PCMARC + RCA68.6ms76.9ms

Receivers

DeviceSignalSettingOutputAudio LatencyVideo Input Lag Equivalent*
Marantz NR1711 (2020)1080p 60Hz 2.0 StereoPure DirectSpeakers6.0ms14.3ms
Marantz NR1711 (2020)1080p 60Hz 5.1 SurroundPure DirectSpeakers6.3ms14.6ms
Onkyo TX-NR585 (2018)1080p 60Hz 2.0 StereoGame DirectSpeakers11.0ms19.3ms
Onkyo TX-NR585 (2018)1080p 60Hz 5.1 SurroundGame DirectSpeakers10.6ms18.9ms
Pioneer VSX-933 (2018)1080p 60Hz 2.0 StereoPure DirectSpeakers11.0ms19.3ms
Pioneer VSX-933 (2018)1080p 60Hz 2.0 StereoStereoSpeakers16.2ms24.5ms
Pioneer VSX-933 (2018)1080p 60Hz 5.1 SurroundPure DirectSpeakers10.5ms18.8ms
Pioneer VSX-933 (2018)1080p 60Hz 5.1 SurroundPCMSpeakers15.5ms23.8ms
Denon AVR-S650H (2019)1080p 60Hz 2.0 StereoDirectSpeakers19.1ms27.4ms
Denon AVR-S650H (2019)1080p 60Hz 5.1 SurroundDirectSpeakers19.0ms27.3ms
Sony STR-DH540 (2013)1080p 60Hz 2.0 StereoPure DirectSpeakers56.5ms64.8ms
Sony STR-DH540 (2013)1080p 60Hz 5.1 SurroundPure DirectSpeakers13.1ms21.4ms
Yamaha RX-V4A (2020)1080p 60Hz 2.0 StereoPure DirectSpeakers67.9ms76.2ms
Yamaha RX-V4A (2020)1080p 60Hz 5.1 SurroundPure DirectSpeakers17.7ms26.0ms

HDMI Audio Extractors

DeviceSignalSettingOutputAudio LatencyVideo Input Lag Equivalent*
OREI HDA-912 HDMI Audio Extractor 18G1080p 60Hz 2.0 StereoAnyHeadphones18.5ms26.8ms
Almencla 5.1CH HDMI Audio Extractor1080p 60Hz 5.1 Surround5.1CHRCA70.5ms78.8ms

* 60Hz video input lag includes an additional 8.3ms to account for the average transmission time of individual pixels from the start of a frame. This rightmost column should be used when comparing audio latency to video input lag.

Complete Test Result Details

A complete list of all of the audio latency tests I have done can be found in this google sheet. This sheet includes exhaustive testing on the receivers mentioned in the above tables. Feel free to make a copy so you can sort and filter!

Why are there no TVs or monitors that have 0ms input lag?

Thursday, November 12th, 2020

The following history is based on an email discussion I had with a display review author back in 2013 that I thought would be valuable to share:

Input lag is commonly understood as the latency (or delay) between the moment a video signal is transmitted and when that video signal is displayed on a TV or monitor. Back in the days of CRT displays, this would be less than a millisecond. But when looking at input lag measurements, one finds that no modern TVs or monitors have an input lag of less than 8ms when running at 60Hz. So why is this?

The reason dates back to decisions made in 2012 or 2013 regarding how to interpret the results from the Leo Bodar 1080p 60Hz Input Lag Tester. This testing device would measure the time between the start of a frame of video and the time that it was displayed on the screen, at three different points on the screen:

Image of the Leo Bodnar Input Lag Tester from the Leo Bodnar online store page
Image of the Leo Bodnar Input Lag Tester from the Leo Bodnar online store page

The results would be different based on which point of the screen the device was held to. Here’s an example of what you would see on a display that has zero video latency and instant response time, like what a CRT would have:

  • Top of screen: 0ms
  • Middle of screen: 8ms
  • Bottom of screen: 16ms

This makes sense because it takes 16.67ms to transmit a video frame at 60Hz. So the 8ms and 16ms readings are showing the transmission time of a frame of video rather than the video latency of the TV/monitor.

Initially, “input lag” results from this device were reported using a measurement at the bottom of the screen. This would include the video latency of the TV/monitor plus the full 16ms of a 60Hz frame transmission time. Unfortunately, it seemed that this input lag testing device would show confusing results with some displays, where the bottom reading would be less than the top reading. It’s possible that these displays would buffer an entire video frame and then present it bottom to top, rather than top to bottom. Or, this could have been an error in the testing device. Either way, it seemed like there wasn’t a way to simply report the measurement at a single point on the screen.

To address the issue that some displays were giving these abnormal results from the Leo Bodnar Input Lag Tester, a number of review sites decided to report input lag as follows:

Input lag = (average video latency at the top, middle, and bottom of the screen) + (average frame transmission time at the top, middle, and bottom of the screen)

Compared to measuring a single point on the screen, this reporting method has the benefit of accounting for displays that might present a frame of video with a different latency for different points on the screen rather than presenting each pixel immediately as they are transmitted to the display. A primary example of when this happens in practice is Black Frame Insertion, where pixels at the top of the screen are delayed more than pixels at the bottom of the screen. Unfortunately, this approach has the downside of including the frame transmission time in the input lag measurement.

It is worth noting that there are very few displays that present from bottom to top. I am personally unaware of any that have this sort of behaviour. This leads me to believe that the errors in the testing device might have been the primary reason for results to be smaller at the bottom of the screen than at the top of the screen. If you are aware of any TVs or monitors that present this way, please let me know so I can amend this comment!

Determining Video Latency without Frame Transmission Time

So long as your video signal does not make use of Quick Frame Transport [QFT] and is not operating in Variable Refresh Rate [VRR] mode, the average frame transmission time across the screen that is included in input lag measurements is a constant value based on the refresh rate of the video signal. This means it can be easily subtracted from an input lag measurement to determine the “pure” video latency of the display.

Refresh RateFrame Transmission TimeAverage Frame Transmission Time Across the Screen
30Hz33.3ms16.7ms
60Hz16.7ms8.3ms
120Hz8.3ms4.2ms
144Hz6.9ms3.5ms
240Hz4.2ms2.1ms

Here’s a chart that shows how to calculate the average video latency from an “input lag” measurement, without including this transmission time. Again, this only works if your video signal does not use QFT or VRR:

Refresh RateAverage Video Latency
30Hzsubtract 16.7ms from “input lag”
60Hzsubtract 8.3ms from “input lag”
120Hzsubtract 4.2ms from “input lag”
144Hzsubtract 3.5ms from “input lag”
240Hzsubtract 2.1ms from “input lag”

Using this final chart, we can discover that there are many modern LCD/OLED TVs and monitors that have close to 0ms of video latency, just like the old CRT monitors of the past!