Picture against sound, measured on the screen: what a camera and a microphone found, 24 October 2026

Why measure on the screen

A player can tell when it hands a picture to the display and a sound to the audio device. It cannot see what happens after that: the display takes its own time to show the picture, and the audio device its own to play the sound. A viewer meets the two only on the screen and at the ear. So to know where Karhu Player’s sound lands against its picture, we measured it there, outside the player, with a camera and a microphone.

How we measured it

A test clip flashes the screen white and beeps at the same frame, once a second. The laptop’s camera, at 30 frames a second with its exposure fixed at 10 ms, faced the screen, and the headset’s earpiece rested on the laptop’s microphone, so one recording holds both the flash and the beep.

A camera and its own microphone are not in step either. In our recordings the camera’s picture ran between about 70 and 165 ms behind its sound, by a different amount in each session. So each session began with a pen tapped on a jar in front of the screen, resting on the jar at each impact: one event seen and heard at once. The offset between the taps’ picture and sound is subtracted from every flash and beep in that session. The camera reads its picture from top to bottom, so the flashes are timed in the same rows as the taps.

The player ran on a mini PC with an Intel N100, full screen on a monitor over HDMI, its sound on a USB headset, under Ubuntu and under Windows 11. To compare builds without moving anything, the player before a change and after it took turns, three times each, in one recording.

What it found on Windows first

The first Windows readings were wrong for a reason none of our counters showed. The player’s audio thread ran at ordinary priority, beside decoding and drawing. On the mini PC it woke late many times a minute, up to 39 ms late when it was due every 10 ms, and each late wake left a short gap in the sound. Nothing in the player was dropped, so nothing counted it. Heard through the headset, the beeps drifted until the sound ran about 150 ms late after a minute. Windows’ own media player, on the same headset, kept them a second apart to within half a millisecond.

The audio thread now registers with Windows’ multimedia scheduler as professional audio. With that, a minute of playback had no late wakes, and its longest gap between deliveries was 10.8 ms. Every Windows reading taken before this change carried the fault, so none of them is used below.

What it found on both systems

The player had not counted the time the audio system itself takes to play a sound, which the system reports. It now does. Measured on the screen and at the earpiece, with positive numbers meaning the sound arrives after its picture:

The tolerance EBU R37 sets for a broadcast chain allows the sound to arrive up to 60 ms after its picture, so both readings were within it before the change and after. But at 25 frames a second +53.8 ms is more than a frame, and a player meant for checking sync should not add a frame of its own.