latencyNanos

Nanoseconds of audio handed over but not yet audible, including everything inside the OS and the hardware.

This is the number the master clock is built on, so an honest answer matters more than a small one. ffplay assumes every device has exactly two buffer periods, which is wrong on most backends and produces a fixed A/V offset of tens to hundreds of milliseconds that nothing ever corrects. Report what the platform actually says, and declare how much it can be trusted through latencyQuality.

The engine reads it for PlaybackStats.audioLatency, from its own thread while the device thread renders, so an implementation must be safe to call concurrently with the render. The audio clock is anchored from the deadline the render callback carries, which needs no latency figure.