Hi there,
I am primarily a software developer, but I have a particular interest in programming hardware to do things that it wasn't quite designed for. Recently I made a 3D video game engine that renders to vector displays like CRT oscilloscopes via an audio stream of a DC-coupled audio interface. ( youtube.com/watch?v=t2i9rZ1DvGo ) I feel like I understand some of the high level concepts, but I know almost nothing about the tools of the trade, so I'm coming here to look for some advice on tools (hardware and software) and equipment. Although I've used an oscilloscope as a vector display in XY mode, I've never used one for any traditional purposes and I really don't know what they're capable of or suited best for. The same could be said for any other type of test hardware equipment.
I have a budget of about $1500 CAD, but don't want to throw my money away unnecessarily.
My project is to develop a method of testing the audio latency of a device like a TV, soundbar, or receiver when given an HDMI signal. I believe I should be able to develop a method that could work with an average Windows 10 computer that has an HDMI output and a typical sound card. But I would like to verify the precision of my test method using proper equipment. While I'm at it, I would also like to measure a "source of truth" video latency to verify the precision of the
Leo Bodnar Lag Testers.
This is where my question comes in:
What type of equipment should I use to measure a "source of truth audio and video latency"?I expect my process for measuring audio and video latency to be similar to the method used in
this article (probably faster to google translate the
original german article) where the author did something very similar to myself: He was developing a new test method for measuring video latency and wanted to verify his test method's precision using industry-grade tools and equipment.
I expect that it will be cost prohibitive to perform this analysis with an HDMI 2.1 packetized signal (4K120Hz or equivalent bandwidth/frequency). This means that I will be looking to only analyze a TMDS signal. I expect I only need need to look at one of the TMDS channels to get an idea of when pixel or audio packet information has changed from previous frames. For a 1080p signal, apparently the pixel clock is 148.5Mhz. For a HDMI 2.0 signal, it's apparently 594 MHz. Because TMDS is DC balanced, I expect that I need to have a fairly high resolution of sampled data to get an idea of when frame data has changed, but I don't need to be able to see clearly what the actual bits are, since I'm not debugging the HDMI signal -- I'm just looking for "when did this sound packet or pixel get sent" by comparing to previous blank/black frames. I should note that the frequencies I mentioned are the pixel clocks, not the bit clocks. I understand that the are 10 bits sent per tick of the pixel clock, so this is more like a 1.5GHz signal for 1080p.
Here are some thoughts I have on how I might do this:
- Turn the audio or video output from the monitor I am testing into a simple voltage. I could use a photodiode for video and a microphone or the line out of the monitor. This part is easy.
- Analyze one of the HDMI's TMDS channels alongside the voltage from the previous point.
- The moment the voltage from the first step goes above a certain value, indicating that a pixel has lit up or sound is being produced, save a snapshot of the last few hundred thousand samples or so. Maybe I could do this using an oscilloscope or some sort of data logger? If I could get a 1.5GHz DC-coupled audio interface, I'd just use a that to record to my computer, but those are usually limited to 192kHz.
- Review the waveforms of the two channels I sampled to determine the time difference between when the pixel was sent over HDMI and when the voltage of the photodiode/mic changed. Again, this is super trivial at a frequency of 192kHz with a DC coupled audio interface because analyzing a waveform with something like Audacity is super easy. But I need to be operating at frequencies that are muuuuuuch higher, of course.
Thanks for taking the time to read through this. I really appreciate you taking the time to help out people like myself who have no formal education on any of these sorts of things

Allen
(Edit: I understand that this might simply not be possible with a $1500 CAD budget. It seems like the article I mentioned, where a similar test was done, used a 12.5Ghz Tek DSA71254 to analyze a 1080p TMDS signal. Their research also suggests that TMDS encoding is such that a new frame that is identical to the last may have different bits, so vsync patterns needed to be used... This might mean that audio packet analysis is impossible without a TMDS decoder...)