Hi Mario,
In your new simple method for measuring timing fidelity:
What are your recommendations for type of photodiode and USB soundcard?
None ;-).
The way i used it, is with a set of two photodiodes + amplifier gizmos i inherited from my friend and ex-colleague Max Di Luca. The intended use of that gizmo he invented/built and all the technical specs, etc., is on this website of his - specificially his article ( New method to measure end-to-end delay of Virtual Reality" by Massimiliano Di Luca published in Presence: Teleoperators & Virtual Environments.) referenced there and also available as a pdf draft for download:
http://massimilianodiluca.info/code_delay.html
I was trying to validate the timing of PTB’s new VRR/FreeSync/GSync support on Linux with open-source AMD and proprietary NVidia drivers, and while i have my ways to hack the Linux AMD driver to run “FreeSync” on non-freesync displays like a VGA/DVI/DP monitor and use my more standard equipment for timing tests, i don’t have this ability with the un-hackable NVidia driver, so i had to resort to good ol’ photodiodes, or a ColorCal2 colorimeter abused as a high-end photodiode. As i don’t have access to an electronics lab, i used the only thing i had laying around, which were Max’s photodiodes, and plugged them into a USB soundcard i had laying around. The measurement with this setup (not using one of the photodiodes or simply placing it at the same position as the other one – redundant), and the PsychPhotodiode driver, proved tedious but doable on AMD + the Retina panel of a Apple MBP 2017. Results are not super-accurate, but validated the basic saneness of the photo-diode setup for rough checking. I knew already from measurements with a Datapixx, a Bits# and some loopback cable, and a Videoswitcher that VRR/FreeSync on Linux has good behaviour and precision
Results on the G-Sync monitor were inconclusive and weird, but that’s a different story.
My point: It worked well enough for my purpose, i think accurate to about ~2 msecs in my case with the Retina panel, but the specific hardware i used is not necessarily optimal for this task. Especially for low frequencies, the high-pass filter of a standard soundcard (around 20 Hz) may add distortions to the measurement. Ideally one would remove the filter from the card if it has such a thing instead of some DSP doing it. But was all not in scope for my quick tests.
The basic approach works fine, because PsychPortAudio can generally time-stamp the onset of captured audio down to the (sub-)millisecond for suitable sound cards, but if you need more than quick spot checks, you’d ideally do some soldering work on the soundcard to turn it into a real cheapo oscilloscope.
OK, which USB soundcard did you use (i.e. that has driver support in Linux)?
According to the paper, the photodiodes are TAOS (now known as AMS) TSL251R, discontinued, but I bought a load of these some time ago as they are great.
Thanks!
Most USB sound cards just work on Linux, because most of them are USB audio class compatible, which means they can be controlled with the generic UAC driver that is part of Linux (or Windows or macOS). In my experience this works well, also timing-wise, unless you somehow managed to get a really shoddy exemplar.
Mine is some random exemplar that i inherited from a trash pile. All i know from the top of my head is that it has “C-Media USB Audio Device” in its name. The case says SD-UAUDV1-C119 and it is only the size of a usb stick. No reason to assume it would be better or worse than any other cheap usb audio card. As i said, i only need this setup for quick and coarse spot checking of timing if the more advanced equipment doesn’t work for some reason.
OK, I normally use my Display++ digital triggers[1] alongside a photodiode recorded with electrophys amplifiers / storage oscilloscopes; but still an optional simpler solution for quick-and-dirty validation is cool, thank you!
[1] remembering the t-lock double flip offset of course!